search

Audio-Injector / Octo

Octo sound card - 8 channel output and 6 channel input sound cards
39 stars 3 forks source link

Dropouts after time. #33

Open markwinger opened 3 years ago

markwinger commented 3 years ago

The is a behavioral issue that seems to be some kind of driver issue. I startup and everything works well. I am running buffer size of 64, sample rat 48k, 6 channels in, 8 out. I have high res times to track processing time, etc. When things first startup, audio io callbacks look very. good. Buffer size and sample rate indicate callbacks should occur on average 1.333ms. I keep track of the highest time since start and it will usually show about 1.5ms. This is great. As long as the time stays somewhat below 2 periods or 2.666ms there should be no dropouts.
The system can run for hours with the longest callback being 1.6ms. But if I let the system run overnight something goes wrong. after many hour (not sure how log), the callbacks will start to get slow. I will see dozens of call backs per minute that are longer that the 2.6 ms, 10-20ms sometimes more. This continues including pops/click associated with dropouts.

If I restart the program with includes unloading and reload octo's drivers, things are good again. If does not appear to be a memory leak. I see no evidence that any kind of throttling is occurring.

Could this be another issue with synchronization? Are the a/d and d/a clocks derived from a common source so they cannot drift apart? I can't think of any other reason for this. Any other ideas?

markwinger commented 3 years ago

Did much digging. I started by inserting a gpio toggle in the audio callback to see what was happening. Looked good for hours, then started alternating between short and long callbacks. So I decided to measure the latency, input to output.

measured 22ms with buffer size 64 and 48k sample rate. I expected 4-6ms. Changed buffer size to 128 and latency changed to 23ms. I then realized I was using "direct sample mixing device" so I changed to "direct hardware device without any conversion".

This would not work but I then found that the output scrambling issue moved the output. So measured the output that twas working and found the latency to be about 6ms with buffer size of 64. Changed buffer size to 32 and measured 3ms latency. Let it run all day(9 hours so far) only 2 dropouts. (I call a dropout if the callback period exceeds 2 buffers).

So this is good, the problem reported only occurs on the "direct sample mixing device" but no on the "direct hardware device without any conversion".

I would like to know what the mixing device does?

flatmax commented 3 years ago

Nice work here.

Dmix is implemented in alsa-lib : https://github.com/alsa-project/alsa-lib/tree/master/src/pcm Look at the pcm_dmix. files.

Have you tried with heightened scheduling priority ? Have a look at this : https://github.com/flatmax/gtkiostream/blob/master/include/ALSA/ALSA.H#L58-L88

I imagine that we both feel it would be best to eliminate all dropouts. I guess I'm suggesting that these dropouts may occur when some system processes startup (possibly due to cron scheduling) and take priority over the ARM's resources with heavy loads.

markwinger commented 3 years ago

I an not having problems with drop out now. I can run 24 hours without a single drop out. This is running at 48k, 64 sample buffer size. My ap does all processing using multiple threads. They are all running with audio-time critical priority.

I have tested with 98k sample and 32 buffer size. This is pushing too much I think. It can handle it but it looks like it is on the edge. So if I test for extended periods I'm sure it will get drops.