mal_device_write__alsa() raising assert mal_assert(frameCount > 0); about miniaudio HOT 19 CLOSED

That was it. I can reproduce it now and I've identified a fix. I just wanted to confirm, when this was happening, were all of you using dmix? That's the only one I was able to reproduce it with.

I've pushed a potential fix to the issue_1 branch. I needed to disable resampling.

Thanks for all your help on this! Hopefully that fixes everything for this issue - let me know if it doesn't work!

from miniaudio.

With this commit sysdefault:... devices and plug:dmix also work for me. I found some 24bit 96kHz flacs in my lib and I tried them with the old version without this commit with sysdefault:... devices and plug:dmix and guess what, they work perfectly and some file generated with audacity in 48kHz also works, so it seems it's only 44.1kHz causing problems, at least on my system.

from miniaudio.

Thanks for the report! I wasn't able to reproduce this on my machines, but I've made a change that I think fixes it. Could you checkout branch "issue_1" and try that out for me? If that doesn't work, could you add the following line just after your config init?:

cfg.alsa.noMMap = MAL_TRUE;

To give some background, the ALSA backend has two ways of delivering audio to the device - memory mapping and write/read functions. The above config disables mmap mode and forces write/read mode instead. Looking at your stack trace it looks like it's choosing mmap mode so it would make it easier to disable it just to narrow it down a bit.

Thanks a lot!

(Cool little project you got there by the way.)

from miniaudio.

Cheers for getting back to us! Yeah, I don't (yet) contribute to MiniGBS; it's all by @baines.

Branch "issue_1" prevents the crash, but leaves MiniGBS still only playing 2 notes before going into a weird state (which I think falls into the domain of @baines).
Adding cfg.alsa.noMMap = MAL_TRUE; enables everything to work on both branches.

Hope this helps.

Update: Upon falling into that weird state, one of my CPUs goes to 100% usage, which we (@baines / insofaras and I are chatting in Handmade Network IRC) guess could be due to it perhaps busy looping the audio_callback.

from miniaudio.

Yeah it's something to do with mmap mode. I'm suspecting there's an xrun happening somewhere and the device isn't getting recovered properly. Will take a more detailed look at this tonight or tomorrow night... It's just difficult because it's not happening on any of my machines :(

Thanks for the feedback!

from miniaudio.

So I've taken another look at this and updated the issue_1 branch with a potential fix. I still haven't been able to reproduce it on my machine, but I have improved the logic that waits for a period to become available for writing/reading.

The documentation clearly says that snd_pcm_avail_update() must be called immediately prior to snd_pcm_mmap_begin() because otherwise snd_pcm_mmap_begin() can return an incorrect frame count (which indeed appears to be happening). I'm definitely doing this in the latest commit that I just pushed. Maybe I'm just misunderstanding something, but I just can't see why this wouldn't be working...

from miniaudio.

Unfortunately the updated issue_1 branch produces the same behaviour as before the update. Perhaps @ic319 is onto something with the idea that maybe "there is something dubious with sysdefault in Manjaro". I'm on Arch here, on which Manjaro is based, and may be falling foul of the same sysdefault setup. Exactly what that setup is, though, I'm struggling to find out...

from miniaudio.

In MiniGBS he initializes it like this mal_device_init(&audio_ctx, mal_device_type_playback, NULL, &cfg, NULL, &audio) which will get here

if (pDeviceID == NULL) {
        mal_strncpy_s(deviceName, sizeof(deviceName), "default", (size_t)-1);
    }

in mal_device_init__alsa so there won't be any custom device name there like sysdefault, it'll just be default and for me it works with no modifications on the default integrated sound card.

from miniaudio.

On my machines, "default" goes through PulseAudio, but @miblodelcarpio mentioned in his first post that he's not running with PulseAudio so I'm suspecting that maybe you might have a different configuration for the default device? That's just a guess...

from miniaudio.

Yes, the default asound.conf goes through PulseAudio. I needed it different some time ago and I forgot about it.

from miniaudio.

I have the same problem on system without PulseAudio so I can also test. Currently with issue_1 branch I can hear one sample and then it hangs, i.e. Enter doesn't work for quit, I have to use ctrl+c.
No problems if I disable mmap.

from miniaudio.

Cheers for the hint, @ic319! Passing "hw:CARD=UAC2" as the pDeviceID to mal_device_init(), makes everything work without (or with) setting cfg.alsa.noMMap = MAL_TRUE;. However, this prevents other applications from playing sound because we're not going through dmix. Passing "plug:dmix" (from here) as the pDeviceID produces the same behaviour as when passing NULL, i.e. two notes before it hangs.

So I wonder if the issue is in the need to detect and handle dmix specially.

from miniaudio.

Thanks @gen2brain! I'm going to get a non-PulseAudio installation set up as soon as I can so I can hopefully reproduce this thing.

I just did a test with "plug:dmix" on my machine and it works fine :(

from miniaudio.

I checked the mmap mode on my debian netbook that uses dmix and it does play, but it was initially choppy and too fast. Running it with LIBASOUND_DEBUG=1 (after undoing minigbs' stderr close hack) showed a message about setting the rate 44100 failing.
I changed the FREQ #define in minigbs' audio.c:64 to 48000 and then it played perfectly.
That's as much as i've debugged it so far, not sure if that is of any help in tracking down the root cause.

from miniaudio.

#define FREQ 48000 fixes everything for me too.

from miniaudio.

Works also for me now, with or without mmap. I don't have anything in alsa config, but by default I think it will enable dmix if card doesn't support hardware mixing.
This also fixed crackling sound I had, I am working on Go bindings/wrapper for this library, and there I had this issue with sound, thought I was doing something wrong, but now it just works. Thanks!

from miniaudio.

issue_1 fixes it perfectly! And I also find that the master branch works fine for all sample rates 48kHz ÷ 2 down to 6kHz, and × 2 up to 768kHz (I didn't bother trying any higher). The (Audio Engineering Society recommended) rates on which it fails are 44.1kHz and 32kHz.

Good job, all!

from miniaudio.

Thanks for helping figure that one out and testing that fix. I'll get this fix plus a few more changes into the master branch and bump the version this weekend.

from miniaudio.

I've updated the master branch with a new version which includes the fixes for this issue. Thanks for all your helping figuring that one out.

from miniaudio.