Mixxx crashes with "PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed"

Bug #1903299 reported by Stefan Wimmer
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mixxx
Invalid
High
Unassigned

Bug Description

I've used mixxx git now for a a couple of weeks and it worked flawless until a week ago (not sure when it precisely started to crash though).

Now I can invoke mixxx and start playing (be it a single track, AutoDJ or previewing a song) but it then crashes with the message shown in the title:

"PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed"

I've attached a complete backtrack trace and also all the information when running the program with the advised arguments in gdb ...

Revision history for this message
Stefan Wimmer (wimstefan) wrote :
Changed in mixxx:
milestone: none → 2.4.0
importance: Undecided → High
Revision history for this message
Jan Holthuis (holthuis-jan) wrote :

Does this also happen with older Mixxx versions (current 2.3 or 2.2 branch)?

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

I haven't tried that yet - give me some time to test this ...

Any more info you need?

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Revision history for this message
Stefan Wimmer (wimstefan) wrote :

OK - I've checked out the current 2.3 branch and compiled mixxx with the same scons arguments and ti's running inside gdb for one hour without a crash :)

I've tested preview on the built-in soundcard with 96000Hz sample rate, loading singular tracks to both decks and playing them on my external Mojo soundcard and also with AutoDJ ...

The only problem I have that I can't use the database from the current main tree build anymore which had quite some ratings & crates I've lost now :-/

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

The database schema is backwards compatible. You can use the current version from main for both 2.2 and 2.3.

What kind of database issues do you experience?

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Revision history for this message
Stefan Wimmer (wimstefan) wrote :

Sorry about the confusion with the database - it is indeed backwards compatible and I misinterpreted some messages I saw passing by in gdb ... it was more about configuration settings coming from 2.4-alpha and even those are compatible with the 2.3 branch. I'm a bit confused after several hours of testing and re-building mixxx manually :-/

Right now I'm still experiencing the segfaults with the original error message even on the 2.3 branch with the Mojo as main soundcard. Next step is testing the app with the built-in soundcard as main device.

You might have read it in the logfile but I mention it anyway: the system is Gentoo ~amd64 with portaudio installed from github. This with regard to the portaudio errors you guys quote - not sure I fully understand what's going wrong there ...

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

OK guys I've spent a couple of hours to see how I can solve the problem and right now things are looking quite good :-D

First of all I've followed the links about PortAudio Uwe posted and applied the patch mentioned there (see attached file). The resolved the segfaults but didn't really help because the music was still playing but the sound was gone ... ;-)

Than I started to investigate more precisely when things stopped working and I saw that it was around the same time I've updated my alsa programs from 1.2.3 to 1.2.4 which also introduced some new packages: alsa-ucm-conf & alsa-topology-conf (I'm sure that's Gentoo specific and I'm not sure what all that means but I still want you to know that this was the biggest change) ... so I decided to go back to alsa-{lib,utils} 1.2.2 (again Gentoo specific versioning inside the ebuild environment). Et voilà things are back to normal again I dare to say after 4 hours of continous playback via AutoDJ without a problem :-D

Why the jump to alsa 1.2.4 caused that problem I can't tell you ... funny thing is that this problem only appears on my laptop and not on my dekstop computer where I'm still running mixxx (main) alongside alsa 1.2.4 without any problem?!?

Anyway I wanted to inform you that for the time being I'm able to use mixxx again :)

I see what I can find out what changes inside alsa caused the problems ...

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Fedora versions:

alsa-lib-1.2.4-5.fc33
portaudio-19-32.fc33

I didn't check the changelogs for custom patches that might be included.

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

Not sure what I can achieve with that information ...

When the problem arose I first started with a different version of mixxx (going from main to 2.3 -> still crashing), then looking at portaudio (building git version with patch -> still crashing -> no patch -> still crashing) and finally to an older version of alsa (1.2.2 -> the problem goes away).

How could I've proceeded in a different way?

Current (working) versions on Gentoo:
media-libs/alsa-lib-1.2.2-r1
media-libs/alsa-oss-1.1.8
media-plugins/alsa-plugins-1.2.2
media-sound/alsa-utils-1.2.2
media-libs/portaudio-9999 (git main)
media-sound/mixxx-9999 (git main)

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Another PortAudio/ALSA fix for testing: https://github.com/mixxxdj/mixxx/pull/3277

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

Thank you so much Uwe!!!
Currently testing on both 2.2 and 2.3 branches with alsa 1.2.4 ... seems to be good so far :)

PS: Thanks by the way for giving me the opportunity to learn how to patch from github ... it's easier than I thought ;-)
Just get the patch with this URL https://github.com/mixxxdj/mixxx/pull/3277.patch and apply it with `git am 3277.patch` ...

Revision history for this message
Be (be.ing) wrote :

It is easier to use Git than mess around with patches... https://github.com/mixxxdj/mixxx/wiki/Using%20Git

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Is your issue fixed now after https://github.com/mixxxdj/mixxx/pull/3277 has been merged?

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

Sorry for not coming back to you earlier but I was testing yesterday all day (& night) with different branches - main, 2.2 & 2.3 - (which takes quite some time to compile this beast on my little laptop ;-)) and different versions of alsa - 1.2.2 & 1.2.4 - and at the moment I think it comes down to one configuration option I (wanted to) use: "Samplerate 96000"

As soon as I use it the segfaults start again ... no matter what mixxx or alsa version I use.
alsa-info.sh states that my internal soundcard supports that samplerate:
```
Codec: Realtek ALC236
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0236
Subsystem Id: 0x17aa390a
Revision Id: 0x100002
No Modem Function Group found
Default PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
```

I don't use any alsa configuration file just the default Gentoo configuration to be sure this doesn't mess up things.
The crashes are irregularly and seem to be related with starting other programs like browsers or other audio programs. But it happens randomly so I'm really not sure what's causing it.

When I run mixxx with "Samplerate 48000" it can play for hours and I can do whatever I want inside the program itself and also with opening other programs ...

Sorry that I can't be of any more help :-/

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Assert the impossible.
Since it tuns out that it is not impossible crashing the app is a bad idea.
We should talk to the port-audio guys to integrate the patch.

The issue can triggered by a delay. Maybe you can work around it by using a bigger buffer size.

Does the crash also happen if you explicit the sound card instead of sysdefault?

During test, I have just experienced a no sound issue with sysdefault + 96 kHz + 10.7 ms.
The second attempt works now.

Out of curious, why do you like to use 96 kHz? Do you have recordings with this sample rate?
Are you able to hear the difference?

Depending on the oversampling algorithm in the DA converter, the result can be worse compared to 44.1 kHz tracks played on a 44.1 kHz sound card, because of the fast linear resampling algorithm in Mixxx. There is a bug to move to a cubic version https://bugs.launchpad.net/mixxx/+bug/1775164.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Here as a PR against Portaudio:
https://github.com/PortAudio/portaudio/pull/344

Revision history for this message
Stefan Wimmer (wimstefan) wrote :

Thanks for the Portaudio patch Daniel!

First I want to answer the question why using 96kHz: most of the music I bought for DJing is 24bit/96kHz and the Chord Mojo I own is perfectly capable of playing those so of course I want to use that as well ... ;-)

Where it goes wrong is that if I want to use 96kHz I have to assign that also to the internal sound card that I'm using for pre-listening. When I try to configure that Mixxx complains that the wrong samplerate is used for the internal card so I created a simple configuration in /etc/asound.conf:
```
pcm.!default {
    type plug
    slave.pcm hw
    rate 96000
}
```

This is why I'm using sysdefault ...
I will give it another try with a bigger buffer size and see if it works.
Perhaps it is an idea to make it possible to define a samplerate for a
specific sound card?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Ah OK, the issue is your asound.conf
It enforces to use the rate 96000 which the device "hw" cannot do.

I think that should be removed.

You need install a resampling stage:

If not already installed, install:
libasound2-plugins

And add:
defaults.pcm.rate_converter "samplerate_best"
to your asound.conf

Revision history for this message
Be (be.ing) wrote :

Can this be closed since the PortAudio PR was merged and released?

Revision history for this message
Damian Wheel (tfwnogf) wrote :

When was it merged? I'm using the 2.3.0 build (Monday, June 28, 2021 10:04:59 PM build), and yet still experiencing this annoying bug every 15min.

Revision history for this message
Be (be.ing) wrote :

The PortAudio fix was merged 2020-12-18 and released 2021-04-06. What distro are you using? AFAIK the only common distros shipping PortAudio 19.7 yet are Arch and Fedora Rawhide (35 alpha). I have already contacted the Debian package maintainers about updating their mixxx and portaudio packages. As far as I know they have not done so.

Revision history for this message
Damian Wheel (tfwnogf) wrote :

Unfortunately I'm running Linux Mint, I guess I will have to wait a while before being able to properly use Mixxx. :-(

Revision history for this message
Be (be.ing) wrote :

I suggest trying the Flatpak from Flathub. It is built with PortAudio 19.7.

Revision history for this message
Be (be.ing) wrote :

Closing as Invalid because this is a bug in an upstream library (which has already been fixed).

Changed in mixxx:
status: New → Invalid
milestone: 2.4.0 → none
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10201

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.