search

mackron / miniaudio

Audio playback and capture library written in C, in a single source file.
https://miniaud.io
Other
4.07k stars 361 forks source link

miniaudio's pulseaudio backend does not work with Fedora 35 #427

Closed weimzh closed 2 years ago

weimzh commented 2 years ago

as title:

$ ./simple_playback test.wav simple_playback: ../miniaudio.h:52300: ma_data_converter_process_pcm_frames__channels_first: Assertion `pConverter->resampler.channels < pConverter->channelConverter.channelsIn' failed. Aborted (core dumped)

Not sure if this is related to pirewire.

Related: https://github.com/grumpycoders/pcsx-redux/issues/714 which has the same issue

mackron commented 2 years ago

Thanks for the report. I've pushed an untested attempt at a fix to the dev branch. Are you able to give that a try?

fes0j commented 2 years ago

Hi, I found this issue after having Problems with the game Mindustry. I had the same error first and with the new fix the game at least starts, but has than now audio.

Hope this feedback helps somewhat.

mackron commented 2 years ago

I've had another report about this. It's because PipeWire is returning an invalid channel map. miniaudio retrieves the device's native channel map so it can do the necessary channel reordering, but for some reason PipeWire is returning AUX channels rather than left/right. I'll be investigating a workaround for this ASAP.

mackron commented 2 years ago

I've pushed an experimental hack to try and workaround this. Are you guys able to give this a try? It's in the dev branch. This will only work around mono and stereo cases. Channel counts > 2 will still have the problem.

This is something that I think should be reported to the PipeWire developers if it hasn't already. If it's a bug in miniaudio I have no idea what it could be that I'm doing wrong (advice welcome!).

weimzh commented 2 years ago

Thanks for the quick fix :)

a quick test:

simple_playback seems ok with the hack pcsx-redux no longer crashes or freezes, however the sound is still incorrect. Switching the driver to ALSA fixes it.

will see if I can report the bug to pipewire later

I've pushed an experimental hack to try and workaround this. Are you guys able to give this a try? It's in the dev branch. This will only work around mono and stereo cases. Channel counts > 2 will still have the problem.

This is something that I think should be reported to the PipeWire developers if it hasn't already. If it's a bug in miniaudio I have no idea what it could be that I'm doing wrong (advice welcome!).

mackron commented 2 years ago

When you say the sound is incorrect, in what way? Is it still just silence, or is the sound distorted? I know it can be hard to describe, wbut what does the glitching sound like?

mackron commented 2 years ago

Also, is it possible to compile with the MA_DEBUG_OUTPUT flag and post the output here? Might be useful to see how the device is being configured.

mackron commented 2 years ago

Can you try increasing the period size? It's done via the device config:

deviceConfig.periodSizeInMilliseconds = 20; /* <-- Trying increasing this. Default is 10. */
weimzh commented 2 years ago

sorry for late reply.

yeah it's hard to describe but I've recorded a short video here, which compares the pulseaudio and alsa backends: https://www.youtube.com/watch?v=qUvB2QvJUyo

weimzh commented 2 years ago

Can you try increasing the period size? It's done via the device config:

deviceConfig.periodSizeInMilliseconds = 20; /* <-- Trying increasing this. Default is 10. */

the code in pcsx-redux has this, which seems to be a pertty small buffer: m_config.periodSizeInFrames = 64; from: https://github.com/grumpycoders/pcsx-redux/blob/main/src/spu/miniaudio.cc

I've changed this to 1024 and it seems OK now.

Anuken commented 2 years ago

Could setting periodSizeInFrames to 1024 instead of the default have negative effects on other platforms unaffected by this bug? I'm wondering if I should add that line as well.

mackron commented 2 years ago

Thanks for checking that for me, and glad that's working for you. 64 is way too small. Also it's usually best if you set it in milliseconds rather than frames because otherwise it becomes dependant on the device's sample rate.

@Anuken Yes, that would affect all platforms. I'm going to make a change to miniaudio to increase the default buffer size for only the PulseAudio backend.

So to summarise this report, there appears to be two bugs in PipeWire: 1) The channel map is returning AUX channel positions instead of FL/FR; and 2) The buffer size needs to be set unreasonably high. This isn't affecting regular PulseAudio, and from discussion with other users outside of this ticket I'll be needing to set it to around 25ms which is ludicrously high (that's even worse than DirectSound from the Windows XP days). This is clearly a bug in PipeWire that needs fixing.

mackron commented 2 years ago

I've pushed a change to the dev branch to use 25ms by default with the PulseAudio backend. This should hopefully work around the PipeWire issue, but it's an unprofessional solution so when the underlying bug is fixed in PipeWire I might change this back.

mackron commented 2 years ago

I've released these PipeWire workarounds. Feel free to open a new issue if issues persist. I've added a note to my internal todo list to apply these workarounds only when PipeWire is being used. Will get to that in a future version. Thanks for the report and testing.

jansol commented 2 years ago

The AUX channel mapping thing sounds like the soundcard in question is set to Pro Audio profile, in which case PipeWire will show all channels as "AUXn". This is an intentional feature and not what PipeWire does by default so sounds like a configuration issue. People who go for the Pro Audio profile are expected to do any one of the following: a) set up a null sink that provides FL,FR channels and forwards them to the right channels of the audio interface b) manually connect the applications as needed c) configure the session manager (wireplumber) to connect applications to the right channels of the right device

There is also a slight possibility that PipeWire falls back to Pro Audio profile simply because it can't find any "consumer" profile for the card. This would be an issue with the alsa device database.

As for the buffer size thing, that sounds fishy and is definitely not supposed to be the case. Sadly I don't know enough to help with that and can only recommend getting in touch with PipeWire devs. They are quite responsive from what I've seen.

davidebeatrici commented 2 years ago

Correct.

PipeWire's PulseAudio implementation is supposed to be a drop-in replacement for the original server, without any quirks. If there is one: it's a bug.