Pi 5 and soundcards - problems and solutions #5743
Comments
|
@gtrainavicius @j-schambacher This is a more open and more efficient place to discuss the required changes than individual issues or private emails. |
|
@pelwell Thanks Phil, for aligning things here. I will summarize our findings and post here. |
|
Full duplex mode is not working with Pisound, for example, starting audio output in one terminal: Then starting arecord: Cuts audio output off immediately, speaker-test gets stuck, and eventually gives -5 (-EIO) error. The Jack backend does not manage to start in full duplex mode: Does this issue fall under this umbrella, or should I create a dedicated one? |
|
You've been beaten to it: #5747 |
|
|
@pelwell I know -off topic, but I don't know where to place it best. It's not a bug or solely related to PI5. You may remember we are working on an amplifier which uses TAS575x in controller mode. Meanwhile, we have the necessary patches in the upstream kernel. |
|
We're very happy to take back-ports. Just cut-and-paste that into a new issue and it will be dealt with promptly. I hope to put together some answers and suggestions in the next day or two, but I agree that setting the pinmux is the main hurdle to choosing the I2S controller at runtime. |
On second thoughts, don't - I'll just do it |
|
Done. |
@pelwell Thanks Phil! And I'll dig next week into the I2S issues while continuing work on the 8 channel driver. |
|
Using i-sabre-q2m overlay with an i2s reclocker HAT is limited to 192KHz sampling rates on the pi 5. Manual/data sheet for HAT is here: https://github.com/iancanada/DocumentDownload/blob/master/FifoPi/FifoPiQ7/FifoPiQ7Manual.pdf It specifies that you can use the overlay mentioned above or the generic i2s dac overlay (my understanding is that's the "hifiberry-dac" overlay). I have tried with both overlays and encounter the same sample rate limitation on the pi 5. Also I can't pass DoP through to my DAC over LVDS on the pi 5 whereas I can on the pi 4. Just get low level noise at 176.4KHz PCM rate. On the pi 4 with the same kernel and overlays the HAT can accept up to 384KHz sample rates and DoP works. config.txt: dmesg: |
|
You say that it is "limited to 192KHz sampling rates on the pi 5" - how does this limit manifest? What happens when you play a 384kHz stream? |
The reclocker HAT fails to lock onto any incoming i2s. It cycles continuously between its two clocks as indicated by its status led's, and in addition, when using an add-on gpio display, it reads "no sig". The connected DAC's display reads "Unlock". None of the above is the case with the pi 4, and both displays show the 384KHz rate. |
|
That tells us that ALSA and the drivers are all happy with the configuration, and that the failure happens when data starts to flow. I should be able to take a look at the signals using the i2s-dac overlay. By the way: The |
|
Just a quick note to say I looked at the signals on a logic analyser today and was able to see the way in which the frequency goes wrong. Hopefully we will have fewer infrastructure disruptions tomorrow and I'll be able to test a fix. |
|
FYI: while working on the various drivers for our sound cards, I've noted that the clock generation for the 24bit format (S24_LE) could lead to a wrong sample frequency (LRCLK). For a 1kHz sine wave you get 750Hz. I guess the ratio of bit clock and LR clock is calculated incorrectly -> 750Hz/1kHz = 24/32. Could be fixed by fixed-bit-clock-ratio of 64... but it's not the solution. I've tracked it down to the hw_params in the dwc-i2s.c, but without docs I can only guess. |
|
Yes, that's exactly what I'm redoing now. |
See: raspberrypi#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
With the main audio PLL at 1.536GHz it is impossible to get I2S audio at 384KHz with a frame length of 64 (32-bit stereo). Reducing it to 1.2288GHz makes it possible. This change is incompatible with a 192MHz audio_sec PLL, so change this to 153.6MHz to make another set of frequencies available. See: raspberrypi#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
With luck, #5999 will solve both of those problems. |
I ran No errors and rebooted, but I'm still seeing the same behavior with 352.8KHz files. Anything else I need to do, maybe in terms of the overlays, or did your PR perhaps only address 384KHz? I don't have any 384KHz handy at the moment to try. |
|
The PR was aimed at 384kHz. There is no good PLL value for the higher multiples of 44100 - the closest we could get with integer divisors is 355.55kHz for 32-bit stereo, or 352.29kHz for 16-bit stereo - but I can look at the failure mode with 352.8kHz. |
|
There is test data at various frequencies here: https://msbtechnology.com/support/bit-perfect-testing/ |
Thanks, will give it a try! So based on your earlier reply, am I understanding correctly that the pi 5 will never be able to support 352.8KHz i2s? |
|
It's worse than I thought - the options are (for 32-bit stereo):
That's not the case.
|
Confirming all is well after updating. The HAT locks onto anything I throw at it now. This will make a lot of audiophiles happy. Thank you! Going to analyze the PR and hopefully learn some things. |
|
One minor update, I'm still seeing the issue with DoP with the updated PR. This one is curious to me since AFAIK nothing in the chain should be the wiser as the DSD bits are "smuggled" in through normal PCM packets. Still, it's minor as the HAT can directly decode the DoP and pass along the native DSD bitstream to the DAC. But it did work on the pi 4 without needing the HAT's decoder enabled. Also, I'm getting the occasional dropout with dsd128 (352.8kHz effective PCM rate via DoP), but not when playing 352.8kHz PCM content. It seems the HAT may be struggling to decode the DoP in some way. |
I don't see how the kernel can be affected by the way the GPIOs and pinmux have been configured. The pinctrl driver doesn't read back the state of the registers to see if a pin is in use - that state is kept in the pinctrl framework, and all pins start out as unclaimed.
Are you saying that putting |
|
Then the question remains, why the kernel can't (re)claim the IOs? I'll do some more testing and let you know. |
Can you explain the difference between these two statements? As somebody unfamiliar with the use of digital audio they sound the same. It would help me if you could briefly outline the data flow in these scenarios (and it sounds like the first one has two versions - one where the HAT does the decoding and one where it passes the DoP through). Unless I get a bad review comment I'll get this PR merged and treat DoP as a separate problem. |
Thanks - that helps to narrow down the problem, because this line definitely does not affect the GPIO setup. Would you mind including the entirety of the EEPROM dt_blob data? I'd like to confirm why it fails on a Pi 5. |
|
Here it is: |
See: #5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
The built-in overlay isn't loading properly because it is incompatible with current kernels. You noticed the messages about deferred probing, and we can see that the cause is the dacpro clock: A quick lsmod shows that the clock driver module hasn't been loaded, and instrumenting the driver confirms that to be the case. Why isn't it being loaded and probed? Because of a change between 4.19 and 5.4 to the way clocks are probed. Here's the original issue: #3481 The TL;DR is that clocks created by modules have to be instantiated by DT nodes that are either children of a |
|
Oh, thanks, Phil! And sorry for the confusion. This means I'll submit ASAP the UUIDs for the hat_map and hopefully even that old stuff gets resolved. I've totally forgotten that problem with the clocks. |
|
All the downstream DT commits get squashed into one when we port to newer kernels, so one commit for all of them is fine. |
One statement makes note of the fact that I'm unable to pass DoP through to my DAC. I just get low level noise on playback and the DAC's display shows that it's interpreting the stream as PCM. But, I can set the HAT to do the decoding of the DoP, which then allows my DAC to "see" DSD and thus allows me to hear the audio. The other statement makes note of the fact that when the HAT is decoding dsd128 (128 x 44.1K) DoP, I hear dropouts, i.e. discontinuities in the sound. Sometimes there is also a popping sound accompanying the dropout. I don't hear dropouts when the HAT is decoding dsd64 DoP, or at any PCM sample rate. Just giving as much info as possible about symptoms. The link I posted describes how in DoP the DSD marker occupies the 8 MSBs of each PCM frame, alternating between 2 values every other sample. If I had to guess I would think something is making it difficult for the FIFO HAT to see those markers at the right time, causing buffer underruns or causing the HAT to see some samples as PCM instead of DSD. Maybe a jittery/drifting L/R clock signal? |
See: #5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
See: #5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
See: #5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
Another data point. I tried with another DAC whose display gives a bit more info (and refreshes more quickly) than the DAC I was previously testing with. Got the same symptoms described above with dsd128 content. But this time I could see that when the dropouts were happening, the DAC's screen briefly reported it was receiving 352.8kHz PCM before switching back to dsd128. Maybe this does indicate that the DoP markers aren't always seen at the right time, perhaps indicating some kind of word select timing issue. With PCM content I could see how this could more easily go unnoticed. I do think I may have heard a few very faint pops when listening to dsd64 content as well. Maybe it's just less severe at lower rates. |
|
But can you account for the fact that 352.8kHz audio sounds OK? Wouldn't timing problems at that level cause samples to be scrambled? And the waveforms look solid on a logic analyser. |
To be honest I don't have a ton of 352.8kHz content. If anything at that sample rate I bet the popping would be so faint that it could easily be missed. DACs do tend to pop and have dropouts when the incoming format changes between DSD and PCM. But this problem is intermittent enough that I could see how you could get a perfect readout with a small enough sample. BTW this doesn't happen with the same HATs on the pi 4. |
See: #5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 6f2a136f210d0e4178fbb5dc3fb5f765ef4c431d from https://github.com/raspberrypi/linux.git rpi-6.6.y See: raspberrypi/linux#5743 (comment) Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
Describe the bug
This issue is meant to be a common place to discuss the changes required for I2S support on Pi 5. Existing issues that cover this area are #5724 and #5741, and some of the content below is copied from them.
Pi 5 (specifically RP1) has slightly different I2S capabilities than those found on the BCM2835 family of processors. It gains the ability to do dual- and quad-lane I2S, but it has separate clock producer (master) and clock consumer (slave) blocks. This means that each overlay has to specify the correct I2S controller - producer or consumer. For most soundcards this is a fixed property, but a few of them can operate in either mode, which causes a problem.
The addition of a "slave" property was a way to solve the problem, but this requires user intervention (and knowledge). A better solution might be to give the overlays for those flexible cards two different i2s-controller properties (or a single property with two label references) - one for each scenario - and modify the driver to choose the correct one at runtime.
There can also be problems for Audio HATs with EEPROMs that have embedded overlays, rather than just including the name of an overlay. By counting how many cards use the I2S interface in producer mode and how many in consumer mode, the old label
i2swas added as an alias for the clock producer block, but for some of the cards this is the wrong choice. If this is wrong for a soundcard with an embedded overlay then there is no choice but to suppress the embedded overlay and load one from the OS image instead (unless the EEPROM can be rewritten).Putting
dtoverlay=in config.txt before any other dt settings disables the loading of the overlay from the HAT EEPROM. The preferred overlay can then be loaded in the usual way. Alternatively, if all the instances of a soundcard have been programmed with the same UUID then a rule can be added to thehat_map, an example of which can be seen in #5742.The text was updated successfully, but these errors were encountered: