Dropouts in RTA in linux

[phofman]

Hi,

I keep getting irregular dropouts in RTA under linux, even at 48kHz with the generous 128k buffer. It is inconvenient when using longer FFTs. IMO the problem is not in alsa sound subsystem, the buffer and period are OK (period time 20ms as defined in java source code, buffer frame size correct as well).

Tested with Java 14 (after adding the missing JAXB API jar to REW working directory) with the new low-latency garbage collector ZGC enabled, the dropout rate was reduced but not completely zeroed. Measuring at 192kHz is quite difficult as the dropouts occur very often. I am surprised measurement with 768kHz was possible in windows.

Please is there a way to add some diagnostics logs to be able to identify the causes of the dropouts/stream discontinuities?

Thanks a lot,

Pavel.

 

[John Mulcahy]

REW uses large internal sample buffers, 8k samples minimum and larger for higher sample rates. I would say the 20 ms buffer you mentioned is quite small for 192 kHz, I thought you planned to increase it? Very strange to have issues at 48 kHz, which REW version are you running?

On macOS 192 kHz seems solid, no dropouts. I did a test build supporting 384 kHz on macOS and it couldn't handle that, lots of dropouts there, hence the 192k limit.

I was a little surprised that 768 kHz worked without any apparent issues on my machine with ASIO.

P.S. You can use the REW scope to see what the dropouts look like.

 

[phofman]

Hi John,

Thank you for your response.

I am currently using beta 39, but I have experienced the dropouts in all previous versions. Back to using java 8 to minimize differences.

I have checked properly the alsa implementation in java and the timing is OK. Java does not use callbacks where that 20ms period time would be critical. Java is using a very simple nonblocking read/write which gives the timing margin of the whole alsa buffer. Its size is the value I configure in REW settings or max buffer supported by the soundcard driver, whatever is lower. My USB soundcard has max buffer 32k frames, the loopback device goes up to 1M frames, i.e. your 128k limit applies. That 20ms period is handled by the soundcard driver in this mode, just updating reading/writing pointer positions for the user space, that is very fast and 20ms is a perfectly safe value even for a very loaded system.

I ran a simple shell command, reading number of available samples (i.e. basically the time remaining to dropout) from alsa debug files (linux kernel offers a virtual filesystem where all status/config data are available for userspace to read/write) and checking for their value. The reading was every 1ms, giving quite precise info about development of the time margin to potential dropout. While the capture margin (capture running FFT) was considerably lower than the playback margin (playback just generating the sine stream), for larger buffer values there would always be enough samples available to avoid the dropouts. Yet the RTA would flick the spectrum from time to time, forcing me to push the reset averaging button to get back to measurement (I use infinite averaging). I am testing this on alsa virtual loopback device (snd-aloop) which is very reliable - I've tested it recently to run at 20MHz samplerate - 100% reliable loopback at such rate.

It really does not seem to be a dropout from the OS sound layer. Perhaps the java GUI charting the spectrum stalls for a moment in linux, causing some dropout somewhere in your inter-threads communication, I do not know.

I tried the scope but it has some minor issues (maybe just in linux, I do not test in windows), it draws (and redraws after param change) the scope trace only after resizing the scope window. Even with that working OK, I do not think I would be able to spot a discontinuity if it occurs once many seconds.

I would love to do more troubleshooting if you put some debug logs, I could enable them e.g. with a java -D property.

Thanks a lot.

Best regards,

Pavel.

 

[John Mulcahy]

Are there particular FFT lengths where you see these dropouts?

 

[John Mulcahy]

I tried the scope but it has some minor issues (maybe just in linux, I do not test in windows), it draws (and redraws after param change) the scope trace only after resizing the scope window. Even with that working OK, I do not think I would be able to spot a discontinuity if it occurs once many seconds.

No issues I'm aware of on Windows or macOS, I don't test on Linux. The scope can capture the last 20 s of data on its longest timebase setting and zoom in to individual samples within that 20 s on the stopped buffer.

 

[John Mulcahy]

I have sent you a message with a link to a test build.

 

[phofman]

The dropouts are solved by enabling OpenGL checkbox in newer beta installers of REW.