mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1017] Error ENOSPC with S24_3 sample format and alsa backend #484
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#484
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rohoog on GitHub (Jun 29, 2022).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1017
I'm not sure it is a librespot or alsa v0.6.0 crate problem.
I use the SA9023 usb audio chip, which should support the S24_3 sample format. If I use a really not supported sample format like S32, I get a different error EINVAL as expected. With S24_3, I get ENOSPC. S16 works fine.
I guess that the sample buffer size used in librespot is not a multiple of the S24_3 frame size (6 bytes), hence the ENOSPC response from the alsa driver.
@roderickvd commented on GitHub (Jun 30, 2022):
Phew it’s a long time ago that I tested
S24_3. I have never had a hardware device that supported that, so I tested it withplughwin the assumption that what works there, would work for hardware devices too.The
S24_3samples are packed as a[u8; 3]so that’s six bytes.Could you investigate with
plughwand maybe drill down on this thing some more?@r-hoogenboom commented on GitHub (Jun 30, 2022):
What do you suggest I should try with
plughw?My understanding is that plughw 'magically' converts sample formats, sample rates (channels?) the chip doesn't support into what the chip does support in software.
Do you want me to use S32 with plughw, which should likely be converted to S24_3 internally by alsa?
Do you want me to use S24_3 with plughw? Then the plughw doesn't need to do any converting and likely the same error will happen.
I can try something this evening (CET).
@roderickvd commented on GitHub (Jun 30, 2022):
Would be great if you could try outputting
S24_3toplughwand perhaps not only this sound card, but another one as well (if only a speaker or even a dummy). If that works then we knowlibrespotputs out 6-byte packets fine.@r-hoogenboom commented on GitHub (Jun 30, 2022):
The thing is that the buffer alignment requirements for the real card might be different whether the plughw is used or not. Maybe the plughw will relax (re-buffer) the buffering to meet the card requirements, hiding the problem.
In general, the audio frames are not allowed to cross the buffer boundary. So a 4KB buffer will work for S16/S32, but not for S24_3. A 12KB buffer will work for both. I didn't hunt your sources to find where the buffering is done.
Anyway, I'll try as requested and report back.
@roderickvd commented on GitHub (Jun 30, 2022):
Yes, that could be. At least we will have elimated the question of the byte packing.
@JasonLG1979 did the latest work on the buffer size, he may know more.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
I would make sure the card doesn't require s24 and not s24_3. But other than that librespot does it's best to set the buffer size to what the card asks for. What does the debug output say?
@JasonLG1979 commented on GitHub (Jun 30, 2022):
As far as size goes the buffer is calculated and set by frame and then we ask alsa how many bytes a period is. Our buffer is 1 period worth of bytes as per alsa.
@rohoog commented on GitHub (Jun 30, 2022):
The exact error message is "ALSA function 'snd_pcm_hw_params' failed with error 'ENOSPC: No space left on device'" (device . hw:CARD=Audio,DEV=0). with plughw:CARD=Audio,DEV=0, the result is exactly the same. With plughw and S32, also the same.
Using the default:CARD=Audio and S24_3 works. I'm not sure if alsa will actually use the 24bit mode of the audio chip then.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
That makes me believe that it's not a librespot specific issue. Have you tried aplay?
@rohoog commented on GitHub (Jun 30, 2022):
Correction: the default:CARD=Audio with S24_3 completely freezes the system without any error message.
Indeed this seems more and more a kernel driver issue.
Let me try aplay, but first I need to find something that generates a S24_3 raw stream.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
You can also use speaker-test maybe?
@JasonLG1979 commented on GitHub (Jun 30, 2022):
I can't remember off the top of my head if will do 24_3?
@rohoog commented on GitHub (Jun 30, 2022):
speaker-test is great! I didn't know that one, thanks.
There is S24_3LE and S24_3BE. I guess librespot will do ..LE on LE machine, right? -- it has to, because the ..BE is not supported.
And indeed also ENOSPC with hw and plughw, the reported buffer size of 174760 is not divisible by 6.
The default:CARD=Audio does not freeze the system with speaker-test.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
Yes LE on LE and BE on BE automatically.
@rohoog commented on GitHub (Jun 30, 2022):
speaker-test 1.1.8
Playback device is hw:CARD=Audio,DEV=0
Stream parameters are 48000Hz, S24_3LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 96 to 174762 ----> divisible by 6
Period size range from 48 to 87381
Using max buffer size 174760 ----> not divisible -- why it uses this instead of the advertized?
Periods = 4
Unable to set hw params for playback: No space left on device
Setting of hwparams failed: No space left on device
@JasonLG1979 commented on GitHub (Jun 30, 2022):
Sounds like a driver/hardware issue to me.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
No idea why it's using the buffer size it is? You'd have to look at the speaker-test source?
@JasonLG1979 commented on GitHub (Jun 30, 2022):
Like I said this does not look like a librespot issue
@JasonLG1979 commented on GitHub (Jun 30, 2022):
Ok silly question. I googled the chip you mentioned and it's not a standalone DAC it's just a USB input controller. Is your device a commercial product or a DIY project. I ask because if there is no DAC chip connected to it your errors start to make more sense.
@rohoog commented on GitHub (Jun 30, 2022):
I guess you're right.
I saw in the speaker-test source that this buffer size is divided by nperiods and then multiplied by that, which causes the reduction by 2. By setting nperiods to 6 via commandline option -P, the buffer size keeps the divisibility but still the ENOSPC.
@rohoog commented on GitHub (Jun 30, 2022):
I use the spdif output of the SA9023 to drive toslink optical.
No need for a DAC on the I2S.
@JasonLG1979 commented on GitHub (Jun 30, 2022):
The next question then becomes does the device on the other end of the cable support 24_3? 24_3 is mostly just used by over USB.
@rohoog commented on GitHub (Jun 30, 2022):
When I try the same device on another (X86_64 instead of aarch64) machine, it works with
speaker-test -D hw:CARD=Audio,DEV=0 -c 2 -F S24_3LE.It is not the SA9023, it is likely the
snd_usb_audiodriver in the aarch64 linux kernel.@JasonLG1979 commented on GitHub (Jun 30, 2022):
Looks that way. You can close this issue then as it's nothing to do with librespot.
@rohoog commented on GitHub (Jun 30, 2022):
Yes the S24_3 is over USB, the spdif frame is full 32 bit samples where only 24 bits are used (8 bits 0 padded).
I agree, definitely no librespot issue. Thanks for the good suggestions anyway.
@JasonLG1979 commented on GitHub (Jul 1, 2022):
S24_3 is not the same as S24. S24 is 24 bits packed in a 32 bit container (padded) But S24_3 is not. It's 24 bits packed in a 24 bit container (unpadded). I know basically nothing about spdif and if that matters at all? Since it works on x86 it must not?
@rohoog commented on GitHub (Jul 4, 2022):
I created an issue for raspberrypi/linux.