MPV crashes when sending DSD audio through PulseAudio #2654
Comments
|
I see no crash, it just refuses to initialize. Pulse probably returns an error, because the samplerate is somehow out of range. We could probably resample to a lower samplerate, but there doesn't appear to be a way to know the maximum sampelrate pulse accepts? |
|
Is https://trac.ffmpeg.org/ticket/3509 of interest/use to this? |
|
Not really. It just shows they had the same problem with ffplay, and solved it by hardcoding the samplerates. (What kind of fix is this? Pulse hardcodes a limit, so ffplay duplicates the limit?) |
|
…oh god, you're right. 😨 I can't believe they actually committed that. Would a "better" workaround be to find some way to "catch" the too-high-samplerate error and retry the audio, downsampling to 192kHz (or maybe even the destination audio device's maximum native rate) while spitting a warning to the terminal? |
|
Well, I doubt pulse considers this a bug, but I don't know what the "correct" way to handle this. Actually, it might be possible that they just document a fixed limit in their API, but if they do, I can't see it. We also call a In the best case, this is actually a PA bug. Maybe you could try to report it? Even if they close it as invalid, at least we'll know. Asking on the freenode IRC channel also might result in helpful comments. |
|
When I first opened this issue, I asked about it and the 192kHz samplerate limit in #pulseaudio, but I didn't get any response. :/ I imagine the official stance on it is something along the lines of “If somebody tries to bring this up, don't make eye contact. If they pressure you about it, mumble something about CPU usage.” That would be good if there were a max‐/card’s‐native‐samplerate API in Pulse, though. |
|
AFAIK you can ask pulse for a preferred samplerate. |
|
Ooh, that gives me an idea for a least‐worst workaround: If PA dies because of too‐high‐samplerate, retry with the preferred one. Does that hold any water? Or is it infeasible/unclean? |
|
Might be possible, but slightly messy, so I'd like to avoid it. |
|
We're looking at this in PulseAudio now: http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-December/025097.html |
|
Reading that thread, I actually found PA_RATE_MAX, and also a patch that fixes I find it a bit strange that the maximum rate (which is really a rather arbitrary value) is part of the pulse client lib ABI - but fine, we can use that to limit the rate. |
|
Something I was thinking: if we're going to be downsampling within the media player at all, why not downsample it to the target card's native rate? MPV resampling 352.8 > 192, only to have Pulse then resample it from 192 to the card's 48 or 44.1, seems like it would introduce more artifacts than is warranted, especially for playback of audio that was intended to be high quality. On December 31, 2015 9:51:48 AM CST, "V. Lang" notifications@github.com wrote:
|
|
Looking at that discussion thread, it looks like they're both fixing the bug in One question: what will MPV resample the audio to if |
It will just fail initialization. But I was thinking it could try to set a default format. What that could be? No idea. |
pa_format_info_valid() does not do this. (Although there is a proposed patch on the PulseAudio mailing list.) See #2654.
ghost
closed this as 
When I play normal audio, MPV works fine and uses
ao_pulseas the default.But when I try to play a
.dsfsound file, it usesao_alsa. This is not a huge problem in itself, except when I try to change audio devices.The above error occurs when these DSF files are output via PulseAudio at all. I tested it with various
--aoand--audio-devicesettings, and found that the only constant wasao_pulseand thedsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/saudio. (I did not have a large variety of DSF files on hands to test, so I only tested the one type.)And the PulseAudio ALSA plugin ignores the client's requested audio device, outputting all ALSA clients’ sound via the default sink. So just using
ao_alsafor DSF files always is not a perfect workaround.The text was updated successfully, but these errors were encountered: