Sound on a B+

Nov 18, 2014 5 Replies
L

Hi all



I'm having a few problems with the audio on my B+ running the minimal raspbian images from

formatting link



Relevant distro/kernel version info: paul@pi:~$ cat /etc/debian_version



7.6 paul@pi:~$ uname -a Linux raspberry-pi 3.12.25+ #700 PREEMPT Thu Jul 24 17:51:46 BST 2014 armv6l GNU/Linux paul@pi:~$

I'm no stranger to linux, but I mostly play in the server space and linux audio is a notoriously tangled pile of mischief and it's got me stumped somewhat.



I've got ALSA working, and got to the point where aplay will hapilly play the audio I want to work with.



However, I want to run some python which uses PyAudio to handle the audio. This is where I'm hitting problems. It seems that PyAudio depends on jackd, which won't run on 3.12 kernels, and the script eventually bombs out with:



FATAL: cannot locate cpu MHz in /proc/cpuinfo



It looks like this isn't fixable without building libjack-jack2-0 from source or rolling my own kernel [1] (neither are something I'm particularly keen to do as I much prefer packages where possible... for lots of reasons.)



So my question is: Can I somehow tell PyAudio (or the underlying portaudio) to ignore jackd and just use ALSA? If not, is there some other way I can fix it?



If it's not fixable, I'm prepared to throw out all this code and reimplent it using some other python module. Before I embark on that adventure though it would be good to know what peoples preferred python module is for audio playback.



Any pointers gratefully received!


-Paul [1]

formatting link


http://paulseward.com
Vote
Twitter Facebook LinkedIn
A

It is installed on my 3.12.31 system. Not sure about running, though. It's jackd2, maybe you are somehow stuck with jackd1?

Vote
Twitter Facebook LinkedIn
L

Sorry, I thought I'd been clear, perhaps I wasn't.

jackd2 installs fine, it just doesn't work because /proc/cpuinfo doesn't include a "cpu MHz" line on ARM processors in the 3.12 kernels. This is a known bug, and stems from the kernel developers making a decision which has broken jackd (which relies on the cpu MHz line)

There Appear to be 4 solutions to this:

1 - back out the change in the kernel that removes that line when running on ARM (which involves running a locally rolled, patched kernel - nope!) 2 - patch jackd2 so that it uses a different number for its timing source, (which involves running a locally rolled, patched version of jackd - nope!) 3 - avoid using jackd and just use alsa, which works.

PortAudio and it's wrapper PyAudio appear to want to use jackd (and pull in the jackd libs when you install them) and Just Die if jackd isn't working.

If it's possible to tell PortAudio or PyAudio not to attempt jackd, I'd love to hear how - this would be my preferred option!

4 - ditch PyAudio and port everything to some other audio handling module, although I'd appreciate some suggestions of modules to use if I'm to go down that route.

If you think you've got a working jackd[12] on a 3.12 kernel, try running the code here:

formatting link
if it plays you some audio I would be delighted, and would have all manner of questions about the contents of your /etc/apt/sources.list

-Paul

http://paulseward.com
Vote
Twitter Facebook LinkedIn
M

Why not? It's straightforward enough to cross-compile a kernel.

Vote
Twitter Facebook LinkedIn
L

Because the target audience[1] for the thing I'm building need something which will keep itself patched without manual intervention (because they're unlikely to be able to handle that) - so stepping outside of apt is pretty much not worth the hastle.

Sure, I could spin up my own repo and maintain a package for anything locally rolled - but that's far more ongoing maintenance overhead than I want.

-Paul [1] Pretty much a bunch of pensioners who get confused enough by reading and sending email - expecting them to maintain an internet connected widget by manually compiling stuff has proven "interesting" in the past.

http://paulseward.com
Vote
Twitter Facebook LinkedIn
M

Fair enough, you're original post didn't say why you couldn't use your own kernel.

You said PortAudio and PyAudio, this link is from someone using Python and PulseAudio on an rPi. Maybe you can use this and write some kind of adapter/shim to map your software's PyAudio calls to this. I've never done any audio work in Python so I have no experience of the PyAudio API. This may provide you with some inspiration.

formatting link

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required