8000 mal_device_write__alsa() raising assert mal_assert(frameCount > 0); · Issue #1 · mackron/miniaudio · GitHub
[go: up one dir, main page]
Skip to content

mal_device_write__alsa() raising assert mal_assert(frameCount > 0); #1

New issue
New issue
Closed
Closed
mal_device_write__alsa() raising assert mal_assert(frameCount > 0);#1
Labels
bug

Description

@miblodelcarpio
miblodelcarpio
opened on Nov 5, 2017

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 to mal_device__read_frames_from_client(), thus triggering the mal_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

Thread 2 (Thread 0x7f0e666485c0 (LWP 886)):
#0  0x00007f0e655b7d4b in poll () from /usr/lib/libc.so.6
#1  0x000055e65a34fabf in main (argc=2, argv=0x7fffe2e63e38) at minigbs.c:847

Thread 1 (Thread 0x7f0e64331700 (LWP 887)):
#0  0x00007f0e655008a0 in raise () from /usr/lib/libc.so.6
#1  0x00007f0e65501f09 in abort () from /usr/lib/libc.so.6
#2  0x00007f0e654f90dc in __assert_fail_base () from /usr/lib/libc.so.6
#3  0x00007f0e654f9153 in __assert_fail () from /usr/lib/libc.so.6
#4  0x000055e65a350fe0 in mal_device__read_frames_from_client (pDevice=0x55e65a567d00 <audio>, frameCount=0, pSamples=0x55e65adf85d8) at mini_al.h:2200
#5  0x000055e65a35258d in mal_device_write__alsa (pDevice=0x55e65a567d00 <audio>) at mini_al.h:5187
#6  0x000055e65a353ef4 in mal_device__main_loop__alsa (pDevice=0x55e65a567d00 <audio>) at mini_al.h:5758
#7  0x000055e65a355f7a in mal_device__main_loop (pDevice=0x55e65a567d00 <audio>) at mini_al.h:7710
#8  0x000055e65a356153 in mal_worker_thread (pData=0x55e65a567d00 <audio>) at mini_al.h:7790
#9  0x00007f0e6588a08a in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007f0e655c224f in clone () from /usr/lib/libc.so.6

Activity

  1. mackron commented on Nov 6, 2017

    @mackron
    mackron
    on Nov 6, 2017
    Owner

    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.)

  2. miblodelcarpio commented on Nov 6, 2017

    @miblodelcarpio
    miblodelcarpio
    on Nov 6, 2017
    Author

    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.

  3. mackron commented on Nov 7, 2017

    @mackron
    mackron
    on Nov 7, 2017
    Owner

    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!

  4. mackron commented on Nov 7, 2017

    @mackron
    mackron
    on Nov 7, 2017
    Owner

    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...

  5. mackron
    added a commit that references this issue on Nov 7, 2017

    ALSA: Don't set a start threshold when using mmap mode.

    56ea288

  6. miblodelcarpio commented on Nov 7, 2017

    @miblodelcarpio
    miblodelcarpio
    on Nov 7, 2017
    Author

    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...

  7. VelvetyWhite commented on Nov 8, 2017

    @VelvetyWhite
    VelvetyWhite
    on Nov 8, 2017

    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.

  8. mackron commented on Nov 8, 2017

    @mackron
    mackron
    on Nov 8, 2017
    Owner

    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...

  9. VelvetyWhite commented on Nov 8, 2017

    @VelvetyWhite
    VelvetyWhite
    on Nov 8, 2017

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

  10. gen2brain commented on Nov 8, 2017

    @gen2brain
    gen2brain
    on Nov 8, 2017
    Contributor

    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.

  11. miblodelcarpio commented on Nov 8, 2017

    @miblodelcarpio
    miblodelcarpio
    on Nov 8, 2017
    Author

    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.

  12. mackron commented on Nov 8, 2017

    @mackron
    mackron
    on Nov 8, 2017
    Owner

    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 :(

  13. baines commented on Nov 8, 2017

    @baines
    baines
    on Nov 8, 2017

    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.

  14. miblodelcarpio commented on Nov 8, 2017

    @miblodelcarpio
    miblodelcarpio
    on Nov 8, 2017
    Author

    #define FREQ 48000 fixes everything for me too.

  15. mackron
    added a commit that references this issue on Nov 9, 2017

    ALSA: Fix a hardware parameter issue with dmix devices.

    d736d65

  16. mackron commented on Nov 9, 2017

    @mackron
    mackron
    on Nov 9, 2017
    Owner

    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!

  17. VelvetyWhite commented on Nov 9, 2017

    @VelvetyWhite
    VelvetyWhite
    on Nov 9, 2017

    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.

  18. gen2brain commented on Nov 9, 2017

    @gen2brain
    gen2brain
    on Nov 9, 2017
    Contributor

    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!

  19. miblodelcarpio commented on Nov 9, 2017

    @miblodelcarpio
    miblodelcarpio
    on Nov 9, 2017
    Author

    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!

  20. mackron commented on Nov 9, 2017

    @mackron
    mackron
    on Nov 9, 2017
    Owner

    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.

  21. mackron commented on Nov 11, 2017

    @mackron
    mackron
    on Nov 11, 2017
    Owner

    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.

  22. mackron
    closed this as completedon Nov 11, 2017
  23. mackron
    added
    bug
    on Dec 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      0