Recording "clips" and "crops" on Raspberry Pi, writing to Pendrive / SD-card

[jofemodo]

Hi @kmatheussen !

We are using your jack_capture in zynthian project, (http://zynthian.org, https://discourse.zynthian.org) for recording the output of the synthesizer to a pendrive or SD-card. Stereo 44.1/48 KHz. The machine can be quite busy when recording, because it's generating/processing audio in RT.

We (me, and other community members) experiment "clicks" and "crops" in (almost) all the recordings we do. We really would love to have the audio recording feature working OK on zynthian (aka. jack_capture on RBPi ;-)

Do you have some idea for solving the problem? Do you think we are limited by the hardware itself? The needed write throuput is not so big ...

200 KB/s

so the RBPi's USB controller shouldn't have problem with it.

Thanks for your help!

[jofemodo]

I miss to say that "clips" and "crops" are not present in the audio output. They are only present in the recorded wav. It doesn't seem Jack Xruns.

[kmatheussen]

When finished recording, jack_capture prints out if it wasn't able to capture all data from jack. See line 1268-1276. Does it print anything?

Another explanation could be that the sound signal is too high, and that this has messed up the sound in a way before it reached jack, and that the sound output you use handle it in a better way than jack_capture. I hope you record to a floating point sound file? If not, that sounds like the most likely explanation.

You can check in a sound editor whether the noise happens because of gaps or distortion (signal is too high).

Also, I don't know if anyone has run jack_capture on a big endian cpu before, but it should work.

On Wed, Mar 20, 2019 at 2:13 AM Jośe Fernando Moyano < notifications@github.com> wrote:

I miss to say that "clips" and "crops" are not present in the audio output. It doesn't seem Jack Xruns.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/jack_capture/issues/26#issuecomment-474645066, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p19ppMciXf4y80Qpo3k058MAIgSKks5vYYtDgaJpZM4b9gzW .

[kmatheussen]

I just listened to the sound posted yesterday in this: https://discourse.zynthian.org/t/zynthian-boxes-in-the-world/130/99

This sounds like there's gaps in the audio file. However, the gaps are not at both channels at the same time, so it doesn't sound like jack underruns. Might be disk related instead. jack_capture does buffer A LOT of sounds in memory before it gives up writing to disk though, so I don't know what happens. If jack_capture wasn't able to write data soon enough, it would take much longer time before we would hear the gaps. But maybe you use smaller buffer sizes for jack_capture than the default settings? Or maybe the SD card was broken in that specific recording.

[jofemodo]

Hi @kmatheussen ! Thanks for your time and suggestions ;-)

We are using the default buffer sizes, as simple like this:

jack_capture --daemon

and we use Jack transport for starting and stopping.

Regarding the SD, the noise is present in every recording, using SDs of different sizes and qualities and also when using USB pendrives. And of course, the needed write speed is really low compared with the real write speed of any SD card or pendrive... so yes, it's strange ;-)

Did you suggest to play with the jack_capture buffer parameters?

Regards,

[kmatheussen]

Do you have any files you can check from the device? In case, perhaps you can change the command line that starts jack_capture into something like this:

./jack_capture --no-stdin --disable-console --jack-transport

"jackcapture$(date).log"

If not, it's pretty hard to know what's happening.

On Fri, Mar 22, 2019 at 12:27 AM Jośe Fernando Moyano < notifications@github.com> wrote:

Hi @kmatheussen https://github.com/kmatheussen ! Thanks for your time and suggestions ;-)

We are using the default buffer sizes, as simple like this:

jack_capture --daemon and we use Jack transport for starting and stopping.

Regarding the SD, the noise is present in every recording, using SDs of different sizes and qualities and also when using USB pendrives. And of course, the needed write speed is really low compared with the real write speed of any SD card or pendrive... so yes, it's strange ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/jack_capture/issues/26#issuecomment-475440745, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p1X8XwsyCNLlG9ar7qnW0qJBDLQ-ks5vZBVugaJpZM4b9gzW .

[kmatheussen]

Alternatively, you have the close and rotate hooks that can be used to execute any command. Bot these hooks have xrun/overrun and disk failure arguments. Perhpaps you can use these hooks to display something for the user of the device if something went wrong?

On Fri, Mar 22, 2019 at 1:57 PM Kjetil Matheussen k.s.matheussen@gmail.com wrote:

Do you have any files you can check from the device? In case, perhaps you can change the command line that starts jack_capture into something like this:

./jack_capture --no-stdin --disable-console --jack-transport

"jackcapture$(date).log"

If not, it's pretty hard to know what's happening.

On Fri, Mar 22, 2019 at 12:27 AM Jośe Fernando Moyano < notifications@github.com> wrote:

Hi @kmatheussen https://github.com/kmatheussen ! Thanks for your time and suggestions ;-)

We are using the default buffer sizes, as simple like this:

jack_capture --daemon and we use Jack transport for starting and stopping.

Regarding the SD, the noise is present in every recording, using SDs of different sizes and qualities and also when using USB pendrives. And of course, the needed write speed is really low compared with the real write speed of any SD card or pendrive... so yes, it's strange ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kmatheussen/jack_capture/issues/26#issuecomment-475440745, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF9p1X8XwsyCNLlG9ar7qnW0qJBDLQ-ks5vZBVugaJpZM4b9gzW .

[jofemodo]

It's solved! The problem was not related with jack_capture. Zynthian autoconnector was disconnecting the port every 2 seconds and producing the "clips". Sorry for disturbing ;-)