CowCat:
Ad alsa dmix: you talk about low latency. Have you compared alsa dmix latency to pulseaudio latency configured for low latency? Pulseaudio And Latency | The Blog of Juho
Alsa dmix has not received any improvements for ages. The reason is PA. Alsa dmix runs at 16 bit only, using very inefficient resampling algorithms only. Either better quality/huge CPU load, or poor quality/acceptable load. Unlike PA which supports libsoxr and 24 bits, of course. Both solutions do no resampling when only one stream is being played. In that case PA is bitperfect for up to 24bits (or 32bits, just a config option), dmix is bitperfect only at 16bits.
IMO using dmix gives you no advantage. Today the recommended path is either direct alsa (hw:X) for single stream, or PA for general usage with mixing streams.
Ad SPDIF clock -> DAC clock: there is no free lunch when merging two clock domains.
1) Recovered clock from the SPDIF stream (master) = DAC clock
This is typical case for duplex soundcards. The jitter of the recovered clock will affect the DA conversion. Tiny latency.
2) Incoming samples at recovered clock speed are resampled with ASRC to clean clock
ESS chips, proper adaptive resampling in software. The jitter is attenuated to an extent, but not completely, it is not possible. More latency.
3) Incoming samples at recovered clock speed are "reclocked" with another clock, no ASRC
All the hardware FIFO products. The incoming jitter is completely attenuated BUT the fifo will eventually under/overflow. How long it will take depends on the FIFO length. The "safer" the margin, the longer the latency, logically. The "acclaimed" FIFOs for RPi have over 0.5s latency. Way more than a properly configured PA chain, unusable for anything else but music playback.
Now pick what you like. The only way to avoid any of the compromises is having only one clock domain - the clock with the DAC. Jackd, PA network chains are timed by the DAC side. No way for SPDIF.
But the question is simple - can you hear the SPDIF jitter? Only a double blind listening test would tell. Maybe you could start here, the test takes just your time, you already have the expertise to set it up. My 2 cents - you will not get a statistically significant positive identification of any difference.
Ad alsa dmix: you talk about low latency. Have you compared alsa dmix latency to pulseaudio latency configured for low latency? Pulseaudio And Latency | The Blog of Juho
Alsa dmix has not received any improvements for ages. The reason is PA. Alsa dmix runs at 16 bit only, using very inefficient resampling algorithms only. Either better quality/huge CPU load, or poor quality/acceptable load. Unlike PA which supports libsoxr and 24 bits, of course. Both solutions do no resampling when only one stream is being played. In that case PA is bitperfect for up to 24bits (or 32bits, just a config option), dmix is bitperfect only at 16bits.
IMO using dmix gives you no advantage. Today the recommended path is either direct alsa (hw:X) for single stream, or PA for general usage with mixing streams.
Ad SPDIF clock -> DAC clock: there is no free lunch when merging two clock domains.
1) Recovered clock from the SPDIF stream (master) = DAC clock
This is typical case for duplex soundcards. The jitter of the recovered clock will affect the DA conversion. Tiny latency.
2) Incoming samples at recovered clock speed are resampled with ASRC to clean clock
ESS chips, proper adaptive resampling in software. The jitter is attenuated to an extent, but not completely, it is not possible. More latency.
3) Incoming samples at recovered clock speed are "reclocked" with another clock, no ASRC
All the hardware FIFO products. The incoming jitter is completely attenuated BUT the fifo will eventually under/overflow. How long it will take depends on the FIFO length. The "safer" the margin, the longer the latency, logically. The "acclaimed" FIFOs for RPi have over 0.5s latency. Way more than a properly configured PA chain, unusable for anything else but music playback.
Now pick what you like. The only way to avoid any of the compromises is having only one clock domain - the clock with the DAC. Jackd, PA network chains are timed by the DAC side. No way for SPDIF.
But the question is simple - can you hear the SPDIF jitter? Only a double blind listening test would tell. Maybe you could start here, the test takes just your time, you already have the expertise to set it up. My 2 cents - you will not get a statistically significant positive identification of any difference.
My ALSA dmix parameters:
rate 48000
period_size 480 (480/48000*1000 = 10ms)
periods 3 (10ms * 3 = 30ms latency)
format S32_LE (32bit signed integer samples)
ALSA plug plugin's rate_converter "samplerate_best"
I could reduce the latency even further, but I haven't bothered, yet. Juho reduced pulseaudio latency down to 20ms. I think I can do it in ALSA dmix, too.
I doubt pulseaudio can keep 20ms latency while CPU and HDDs are in full load.
My ALSA dmix configuration withstands all forms of heavy loads with 30ms latency without ALSA xruns. Juho hasn't subjected pulseaudio setup to repeated stress tests.
With 30ms latency, lip sync is no problem.
I think I could in the form of pops and crackles. Given enough time, SPDIF clock may drift sufficiently away from DAC clock and cause zita-a2j resampler to produce xruns while the system is under heavy loads. Xruns are audible as pops and clicks.
Unless every audio equipment is tightly united under one clock domain, xruns are possibilities. I think Audio Video Bridging - Wikipedia is the future solution to this although AVB equipments are quite expensive.
Last edited:
Reclocking always requires a FIFO buffer. Any buffer will over/underflow, just a matter of running time and the clocks frequency difference, unless some form of adaptive resampling is used. In this specific example a 500ms buffer (huge latency acceptable only for music playback) would hit its limit in 4.5hour https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5909816
The library libsamplerate is very inefficient, a decent CPU core is required to handle that setup without xruns. And it runs at 16bits, that S32_LE is downsampled at the input and upsampled at the output, the conversion runs at S16_LE Support for libsoxr in alsa rate plugin | Blog IVITERA a.s.
But those are buffer under/overruns, not jitter.
Yes, that is why studios use distributed master clocks, PC audio chains are timed by the soundcard clock (incl. proper audio network protocols), etc. SPDIF always carries clock, and the chain downstream either respects that clock or implements adaptive resampling (or uses the dumb consumer-level fifos).
Right. I'm not an expert in audio.
Whatever I did, I could not eradicate the possibility of buffer xruns from zita-a2j although I seemed to have done so in practice.
Long-term clock drift could make buffer xruns more likely.
My CPU is beyond enough to handle libsamplerate comfortably. pulseaudio is not designed to keep low latency under very heavy loads. At least, I subjected ALSA dmix to heavy work loads without xruns.
If you know how to fiddle with process priorities, you can give lowest priorities to heavy compilation tasks to avoid xruns.
What about speexrate and lavrate? Do they run at 16 bits, too? Do you recommend any specific rate converter?
Last edited:
I usually output test signal (1kHz sinewave) from ADC via SPDIF or IIS when I want to have exact FFT bin with the rectangular window. DAC output without ASRC can be synchronous to the ADC clock since DAC is a slave device. If you use SPDIF of the ES9038, the internal ASRC cuts out the synchronous chain; DAC output is synchronized to the ASRC clock. In this case, ADC can't have a synchronous sampling where the rectangular window isn't allowed.
If you can make ES9038 a master, it's not impossible to do synchronous sampling. But few DAC can become a master because they usually don't have an output signal which is necesary to make ADC a slave. My DIY DACs without ASRC can be synchronous to ADC; the rectangular is possible.
I'm afraid I have a misunderstanding about your setup since I don't know what jackd means. But I guess your SPDIF is only in the digital domain. If so, your chain is free from SPDIF jitter. Jitter exists only in the analog domain. Discrete data in the digital domain uses another technical term, setup and hold. SPDIF in the digital domain usually has enough headroom: no setup and hold violation. Unacceptable jitter in the digital domain ends up sampling error. The only problem often occurs is buffer overflow: pop noise.
If your DAC used with Rpi is the IIS interface, jitter of Rpi IIS is larger than those of SPDIF. But no problem if you are satisfied with the current setup because jitter oriented noise is almost CD quality as long as I have measured. The quantization noise of the CD system(-98dBFS) is usually neglectable.
Edit: No jitter in the digital domain means sampled data. The sampled data itself is already jitter-free though jitter can cause sampling error.
Last edited:
In my limited experience, toslink is probably one of the lesser of evils in digital audio. Galvanic isolation, no issues with jitter IRL, easy to lock bit depth and sampling rate.
USB dacs benefit heavily from isolators.
HDMI is alright if you ONLY watch video, a bit of sound processing then shoving audio through HDMI gave me a mediocre experience at best. Lots of sync related issues if you like to game and/or use the setup for playing music (like with a keyboard using MIDI).
alsa-lib/pcm_rate.c at master * alsa-project/alsa-lib * GitHub
Search * convert_s16 * GitHub
All rate plugins implement the convert_s16 method...
I can only recommend libsoxr
I was playing with pulseaudio. I was disappointed by its port system and its complexity. Its port system cannot switch between speakers and headphones. Rather, it was preventing me from doing so manually.
I wouldn't want to use it to tweak my audio system.
I'd either use SPDIF or just add a pair of speakers to Raspberry Pi 3 B+.
If any major web browser supported JACK properly, I would have used jack and netjack only.
Firefox supports JACK, but its JACK support is a bit disappointing.
I wouldn't want to use it to tweak my audio system.
I'd either use SPDIF or just add a pair of speakers to Raspberry Pi 3 B+.
If any major web browser supported JACK properly, I would have used jack and netjack only.
Firefox supports JACK, but its JACK support is a bit disappointing.
Last edited:
PA is a complex solution for complex requirements. IMO the best PA specialist around is Jürgen Pulseaudio Crossover Rack - multi-way crossover design & implementation with linux
I remembered that if my desktop computer's audio depended on whether or not raspberry pi is working correctly, I would suffer no audio for hours and days when raspberry pi needs repair.
A bit of redundancy is needed for necessary repairs.
I concluded that I shall just give a dedicated pair of speakers to Raspberry Pi 3 if I ever wanted audio for Raspberry Pi.
Maybe, I will use jack and netjack to allow JACK applications to send audio to Raspberry Pi.
Minimal solutions are often the best.
A bit of redundancy is needed for necessary repairs.
I concluded that I shall just give a dedicated pair of speakers to Raspberry Pi 3 if I ever wanted audio for Raspberry Pi.
Maybe, I will use jack and netjack to allow JACK applications to send audio to Raspberry Pi.
Minimal solutions are often the best.
Last edited:
Decent soundcards have the SPDIF coax output galvanically isolated with a signal transformer.
The jitter "debate" for toslink is as xx3... says not a question of data contamination from jitter - this can not happen by just transporting or storing sampled data. The problem with toslink lies in that from toslink, one can derive a clock to govern the D/A process - this is where the potential problem lies - s/pdif is not a good clock conveyor - this clock will be unstable due to link jitter. But a very good data conveyor AND it provides ideal galvanic isolation as well as enabling any drive or streamer to be placed far away from the delicate D/A.
//
AND it provides ideal galvanic isolation as well as enabling any drive or streamer to be placed far away from the delicate D/A.//
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.