-
-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mal_device_write__alsa() raising assert mal_assert(frameCount > 0); #1
Comments
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.) |
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). 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. |
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! |
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... |
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... |
In MiniGBS he initializes it like this
in |
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... |
Yes, the default asound.conf goes through PulseAudio. I needed it different some time ago and I forgot about it. |
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. |
Cheers for the hint, @ic319! Passing "hw:CARD=UAC2" as the pDeviceID to So I wonder if the issue is in the need to detect and handle dmix specially. |
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 :( |
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 |
|
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! |
With this commit |
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. |
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! |
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. |
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. |
What's happening?
MiniGBS successfully launches and plays two notes before segfaulting. The backtrace (below) appears to reveal that the crash is in mini_al with
mal_device_write__alsa()
passing a frameCount of 0 tomal_device__read_frames_from_client()
, thus triggering themal_assert(frameCount > 0)
. I'm not sure of the relevance of this, but I am on plain ALSA (i.e. without PulseAudio) using the dmix plugin for mixing.Do you have enough information here, or any suggestions for further information I can provide to help us get to the bottom of this?
Versions
mini-al: 0.4
MiniGBS: commit baines/MiniGBS@ef080da
alsa: 1.1.4.1
Linux: 4.13.11
Backtrace
The text was updated successfully, but these errors were encountered: