wavrec ring buffer

[m-r-s]

Mir ist aufgefallen, dass am Ende einer Serie von Aufnahmen immer das
Ende der vorherigen Aufnahme gespeichert wird.
Eventuell ein Problem mit einem Ringpuffer?

Beispiel:

Reale Abfolge: ABCDEFGHIJK
Aufnahme 1: ABC_
Aufnahme 2: EFGD
Aufnahme 3: IJKLH

[pmaanen]

Konnte ich lokal nicht reproduzieren. Kannst du die Schritte rum Reproduzieren genauer beschreiben, am besten mit der Konfigurationsdatei?

[m-r-s]

Ja, im Prinzip passiert es auf dem Prototypen mit Raspbian und openMHA 4.7.0 so wie ich es dort aktuell konfiguriert habe [1].
Auf meinem Notebook (mit Ubuntu 18.10) bekomme ich zur Zeit gar keinen Output mehr aus openMHA (zumindest mit den Versionen 4.8.0 und 4.7.0, die ich getestet habe).
Leider weiß ich grad nicht woran es liegt und hab momentan kaum Zeit nach Fehlern zu suchen.
Wenn ich wieder irgendwo ein funktionierendes openMHA außerhalb des Raspi habe versuche ich es nochmal nachzustellen und liefere eine bessere Anleitung.

[1] https://github.com/m-r-s/hearingaid-prototype/blob/master/openMHA.cfg#L19

[pmaanen]

Das hilft schon weiter, danke! Dass es auf dem RasPi auftritt, aber auf meinem x86 nicht, spricht schonmal dafür, dass es ein problem im FIFO ist. Auf x86 sind ja eventuell manche Operationen implizit atomic, für die das auf ARM nicht gilt.

[pmaanen]

Hi Marc René ,
I could reproduce the bug on my mac with the attached configuration and test script.
However, changing the date format to unix time stamps makes the problem disappear. I am currently at a total loss as of why. Can you confirm my observation?
test.zip

[pmaanen]

Replacing cp in commander.sh: by mv also helps. This comes most likely from the fact that 'cp' is not atomic while 'mv' is. I created a corresponding pull request. However, I am still not sure if this is only a workaround for a bug in wavrec or if wavrec works 'as intended'.

[m-r-s]

I have to admit that I have several simultaneous problems with openMHA and currently I don't know how/if these might be interfering. I compiled openMHA v4.8.1 from the sources for these tests.

First, on my Desktop PC (Ubuntu 18.10 on Intel(R) Xeon(R) CPU E5-2630) I ran your test script with a jack dummy device and 1024 samples fragsize.
I fed a sweep of 30 seconds length into MHA via Audacity and started the unmodified test.sh script.
You can see the result in the screenshot. The first file is the generated sweep, below the different recordings. First, the durations are not correct, and in the seconds recording something went horribly wrong. So its probably not only the datestamp. The recordings also show some gaps (maybe due to Xruns, which I would have to check)

On my Notebook (Ubuntu 18.10 on AMD Ryzen 5 2500U) the very same procedure results in wav files of 80 bytes length (probably only the wav file header). I have to say that on this device (also with older self-compiled versions of openMHA) I could not get any output from openMHA anymore. The same happend to a student who is working with an Intel-based Thinkpad on Ubuntu 18.10 with the latest openMHA installed from the deb-repository this morning.

[pmaanen]

Some observations: It is indeed possible that wavrec closes an old file before the new one is opened. A fix for this will be released soon-ish.
What can however not be controlled from within MHA is if the client waits for the audio file to be closed before copying or moving it and only then tries to open a new file. I recommend using mktemp to get a new, guaranteed unique filename for every audio file, e.g.:

  local DURATION=$1
  local TARGETFILE=./$(gdate --iso-8601=seconds)".wav"
  local TMP=$(mktemp --suffix=.wav | sed 's/.wav//g') #Create .wav tempfile but keep only prefix
  (echo "mha.wavrec.prefix = $TMP" | nc localhost 33337 2>&1 1>/dev/null) &
  (echo "mha.wavrec.record = yes" | nc localhost 33337 2>&1 1>/dev/null) &
  sleep "$DURATION"
  (echo "mha.wavrec.record = no" | nc localhost 33337 2>&1 1>/dev/null) &
  mv $TMP".wav" "$TARGETFILE"

[hendrikkayser]

Fixed in release v4.9.0.