SPDIF output audio gaps
07-19-2022, 10:26 AM
Hi there,
TL;DR: S/PDIF output is choppy, unclear whether hardware or software issue, any insights appreciated.
I got a ROCKPro64 running Debian stable (with the kernel pulled in from backports). I modified the devicetree to enable SPDIF, by disabling the other two i2s blocks and enabling the SPDIF blocks. I also re-routed the SPDIF signal to the Pi2 GPIO header (using the alternate pin which was already provisioned in the devicetree), because I didn't have a compatible 2mm pin socket available, and delivery times were in the order of months for those. I am connecting via a hand-soldered coax cable to the amp. I tried different cables and adapters to rule out the cabling as a source of problem.
S/PDIF output works in principle, but there are issues. In particular, the amplifier will irregularly fail to recognize the signal for a short moment (it has indicator lights for S/PDIF PCM which turn off briefly), like some kind of synchronization loss. This causes a gap in the audio.
After looking at the amplifier schematics (it is a Denon AVR-1910 and the service manual can be found on the internet), I realized that the signal is tied to GND using a 75 ohm resistor, which would result in significant peak current being sourced from the RK3399 GPIO. To mitigate that, I added a 2N7000 N-FET as driver, powered from the 5V rail with a 75 ohm resistor. This results in 33mA of peak current, I suppose, which should be fine for the 5V rail (any USB device may need more than that).
That way, I hope to have ruled out any cabling/power issues on the transmission line.
I am currently running nothing except mpd on the box. I tried with pulseaudio inbetween mpd and ALSA, but that did not fix the issues (although I *think* it reduced the issues somewhat, not 100% sure).
The rate of issues seems to correlate with the kind of content played back. 44.1 kHz 16 bit content seems to work better than 48 kHz 24 bit content. 96 kHz 24 bit content is completely unplayable (all you can hear are irregular pops on the output, somewhat like light drizzle rain on a metal roof). mpd is not saturating the CPU; it is between 5% and 30%, depending on the ALSA buffer and period time configuration. (With a buffer_time of 0.5s and a period_time of 1ms, I can get 96 kHz content to play somewhat, but with many, many gaps). There's also no significant iowait going on. Swap is turned off.
I took out my oscilloscope and looked at the signal on the wire and I noticed that most of the time (not always, but that may be my scope failing to trigger properly) when a gap occurs, the S/PDIF signal is interrupted. The smallest gap I saw was 22 microseconds. However, ALSA does *not* report a buffer underrun (via the EPIPE error code) to the application. (I also saw some significant ringing at the rising edges of my simplistic driver, which I removed with a 100pF capacitor in parallel to GND, but that did not change the issue.)
I am a bit at a loss at where to look at next. With ALSA not reporting an underrun, I'm not sure if this is a hardware or a software issue.
I saw someone else report a similar problem, but I can't find it anymore in the forums (the search is broken for me).
I'm not sure what to look at next. I'm not 100% sure this is a hardware problem, it may also be in the Linux kernel or whatnot. Feel free to move this thread if appropriate. I am trying to reproduce the issue with speaker-test currently, but so far I wasn't able to (unless when tweaking the buffer sizes well below any sensible threshold, at which point -EPIPE *is* returned from ALSA, suggesting that that then is another issue). Because of this, I decided to post this in the Linux subforum instead of the hardware one.
I appreciate any kind of input and I'm more than happy to provide scope traces, config files, schematics or anything else which may be useful in debugging this. Because I'm at this point rather clueless where to even start, I decided against uploading a swath of data, but don't hesitate to ask.
kind regards & thank you for reading,
jssfr
TL;DR: S/PDIF output is choppy, unclear whether hardware or software issue, any insights appreciated.
I got a ROCKPro64 running Debian stable (with the kernel pulled in from backports). I modified the devicetree to enable SPDIF, by disabling the other two i2s blocks and enabling the SPDIF blocks. I also re-routed the SPDIF signal to the Pi2 GPIO header (using the alternate pin which was already provisioned in the devicetree), because I didn't have a compatible 2mm pin socket available, and delivery times were in the order of months for those. I am connecting via a hand-soldered coax cable to the amp. I tried different cables and adapters to rule out the cabling as a source of problem.
S/PDIF output works in principle, but there are issues. In particular, the amplifier will irregularly fail to recognize the signal for a short moment (it has indicator lights for S/PDIF PCM which turn off briefly), like some kind of synchronization loss. This causes a gap in the audio.
After looking at the amplifier schematics (it is a Denon AVR-1910 and the service manual can be found on the internet), I realized that the signal is tied to GND using a 75 ohm resistor, which would result in significant peak current being sourced from the RK3399 GPIO. To mitigate that, I added a 2N7000 N-FET as driver, powered from the 5V rail with a 75 ohm resistor. This results in 33mA of peak current, I suppose, which should be fine for the 5V rail (any USB device may need more than that).
That way, I hope to have ruled out any cabling/power issues on the transmission line.
I am currently running nothing except mpd on the box. I tried with pulseaudio inbetween mpd and ALSA, but that did not fix the issues (although I *think* it reduced the issues somewhat, not 100% sure).
The rate of issues seems to correlate with the kind of content played back. 44.1 kHz 16 bit content seems to work better than 48 kHz 24 bit content. 96 kHz 24 bit content is completely unplayable (all you can hear are irregular pops on the output, somewhat like light drizzle rain on a metal roof). mpd is not saturating the CPU; it is between 5% and 30%, depending on the ALSA buffer and period time configuration. (With a buffer_time of 0.5s and a period_time of 1ms, I can get 96 kHz content to play somewhat, but with many, many gaps). There's also no significant iowait going on. Swap is turned off.
I took out my oscilloscope and looked at the signal on the wire and I noticed that most of the time (not always, but that may be my scope failing to trigger properly) when a gap occurs, the S/PDIF signal is interrupted. The smallest gap I saw was 22 microseconds. However, ALSA does *not* report a buffer underrun (via the EPIPE error code) to the application. (I also saw some significant ringing at the rising edges of my simplistic driver, which I removed with a 100pF capacitor in parallel to GND, but that did not change the issue.)
I am a bit at a loss at where to look at next. With ALSA not reporting an underrun, I'm not sure if this is a hardware or a software issue.
I saw someone else report a similar problem, but I can't find it anymore in the forums (the search is broken for me).
I'm not sure what to look at next. I'm not 100% sure this is a hardware problem, it may also be in the Linux kernel or whatnot. Feel free to move this thread if appropriate. I am trying to reproduce the issue with speaker-test currently, but so far I wasn't able to (unless when tweaking the buffer sizes well below any sensible threshold, at which point -EPIPE *is* returned from ALSA, suggesting that that then is another issue). Because of this, I decided to post this in the Linux subforum instead of the hardware one.
I appreciate any kind of input and I'm more than happy to provide scope traces, config files, schematics or anything else which may be useful in debugging this. Because I'm at this point rather clueless where to even start, I decided against uploading a swath of data, but don't hesitate to ask.
kind regards & thank you for reading,
jssfr