Pyalsaaudio & alsa-lib version matching

[bkekelic2]

Hello,
I'm wondering which version (tag) of pyalsaaudio corresponds to which version of the alsa-lib.
Currently, on my obsolete Buildroot system (from ca. 2019.) I'm using:

• pyalsaaudio: 0.8.4
• alsa-lib: 1.2.1.2

I would like to update pyalsaaudio to newest/newer version, so I guess I will need to update alsa-lib also, to match the versions.
Do you have such a list if this question is relevant? I checked docs but couldn't find it.

Thank you very much.

[larsimmisch]

I didn't keep notes like that and also, it might not be needed. If it compiles: great.

[bkekelic2]

I've tried:
pyalsaaudio: 0.10.0 (newest)
alsa-lib: 1.2.11 (newest)

...and it is not working. It compiles but I cannot create PCM object (alsaaudio.ALSAAudioError: Invalid argument [default]).
Same as when I tried slightly older version of alsa-lib:
pyalsaaudio: 0.10.0
alsa-lib: 1.2.10
alsa-utils: 1.2.9

But then, when I set slightly older version of pyalsaaudio it worked:
pyalsaaudio: 0.9.2
alsa-lib: 1.2.10
alsa-utils: 1.2.10

As I'm using Buildroot OS, it fetches packets from PyPI. I'm wondering why the release date of the newest packet (0.10.0) on the PyPI is April 2023, and on the GitHub I can see that the version tag of the 0.10.0 is from February of 2024 ?

[ossilator]

at this point this is somewhat obviously a bug report which is just masquerading as a question.

i'm not aware of pyalsaaudio using any even remotely new alsa functionality. i just reviewed the git history 0.9.2..0.10.0, and i found nothing obvious, either.

so either i'm blind, or one of these is happening:

• one of the seemingly innocuous changes broke something, e.g. 1c1af45
• you have a build problem that affects only the newer version for some reason

so first try building from git and confirming that it's indeed only the pyaa version. then use git-bisect to find the culprit.

you can try using strace to see what alsa call actually fails, and for comparison one where it works. if you post the logs, please cut them down to the actually relevant part (there will be tons of irrelevant stuff from python).

the tag date is wrong because we rewrote the slightly messed up history. don't worry about that.

[bkekelic2]

Thanks for the idea, I will check when I will have some time for this and eventually open the issue, if any.

[RonaldAJ]

@bkekelic2 Do you have a minimal example of the offending code?

[bkekelic2]

I don't have this build anymore, it will require some time and effort to build and test it again, but I remember that this bare minimum example was not working:
import alsaaudio
device = alsaaudio.PCM()
+all different combination of c'tors were not working.

Although, on the current working version (mentioned above) this is ok, and works.

[larsimmisch]

It smells like an issue with the PCM device name default, and I'd recommend looking at the output of aplay -L, or from a python shell:

import alsaaudio
alsaaudio.pcms()

This might indeed be a bug as @ossilator points out. Feel free to create an issue and if you do, it would be really helpful if you could identify the breaking commit with a git bisect.

[bkekelic2]

Thanks for the idea, but I already tried it. Also, tried to put different device names when creating PCM object, and even empty c'tor as you did in the docs examples. All of the above failed with the same error, so eventually I left it aside as I'm not an expert in this field.
Also, I tried to use some invalid c'tor params to see if I will get different error, and yes, I got them, so its obvious that it passes that point in the source code, and that the error is somewhere else.

But yes, I agree, this discussion is probably not the best place to discuss about the issues.