ALSA drivers?

I know they're in beta but where do I get them from? I recompiled kernel from git but still no luck!

ta

[dom]

You also need updated start.elf from github (https://github.com/raspberrypi/firmware/tree/master/boot).

Something like:

sudo apt-get install alsa-utils

sudo depmod

sudo modprobe snd-bcm2835

sudo aplay norah.wav

(assuming you have a norah.wav)

should get sound out.

You legend thank you.

PS - why isnt the module loaded with udev (or whatever the autoloader is)?

drdevil44 said:

PS - why isnt the module loaded with udev (or whatever the autoloader is)?

At the following boot it should auto load? Unless there is something blacklisting it?

[dom]

drdevil44 said:

PS - why isnt the module loaded with udev (or whatever the autoloader is)?

Because it is alpha and causes crashes and hangs...

Sorry, I mean't what is 'preventing' it from loading? I cant see it in the blacklist.

[abishur]

Asked this in another thread right as it died (doh!) but I was wondering if some of the driver problem (too heavy on the CPU) might be alleviated if the audio on the HDMI was set to pass-thru.  Is there any way to enable this on the drivers or after they are installed?

[dom]

Abishur said:

Asked this in another thread right as it died (doh!) but I was wondering if some of the driver problem (too heavy on the CPU) might be alleviated if the audio on the HDMI was set to pass-thru.  Is there any way to enable this on the drivers or after they are installed?

HMDI Passthrough allows AC3 and DTS (there are other formats but they are very rarely supported) to be decoded by receiver or TV.

Most TVs won't support this.

It won't help for the common cases of games audio, or mp3 or ogg.

CPU isn't really the issue. I can play mp3 through ALSA at about 20% CPU utilisation.

What I need is someone who knows about ALSA to look at the driver and suggest what might be wrong. Howver there are very few people who know about ALSA.

[abishur]

dom said:

Abishur said:

Asked this in another thread right as it died (doh!) but I was wondering if some of the driver problem (too heavy on the CPU) might be alleviated if the audio on the HDMI was set to pass-thru.  Is there any way to enable this on the drivers or after they are installed?

HMDI Passthrough allows AC3 and DTS (there are other formats but they are very rarely supported) to be decoded by receiver or TV.

Most TVs won't support this.

It won't help for the common cases of games audio, or mp3 or ogg.

CPU isn't really the issue. I can play mp3 through ALSA at about 20% CPU utilisation.

What I need is someone who knows about ALSA to look at the driver and suggest what might be wrong. Howver there are very few people who know about ALSA.

True, true, but it would help for those (like me ) who plan to initially hook it up through a receiver.

But it won't help for the mp3 or ogg or game audio.  Rats.  Maybe the xmbc peps could  point you in the right direction?

dom said:

CPU isn't really the issue. I can play mp3 through ALSA at about 20% CPU utilisation.

What I need is someone who knows about ALSA to look at the driver and suggest what might be wrong. Howver there are very few people who know about ALSA.

so does MPD work fine on the RPi ? I want to use it as INetRadio and MP3 Player vie MPD

can't we use the roku 2 alsa drivers? as they made it available as open source components and it should be fully functional

afaik the roku 2 has the same soc as the pi

[dom]

mpd works fine. I listened to radio 1 for a couple of hours and it was perfect.
The ALSA driver does share code with Roku"s tree, however their code branched away years ago and communication with the GPU is very different now, which means the implementation is quite different.

dom: perhaps you could post links to the hardware audio datasheets and the code for the driver and more us would be able to peer over the code.

[dom]

The code is:

https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm

there's some information in the discussion of how the interface to GPU works here:

https://github.com/raspberrypi/firmware/issues/2

Is there any info on this vchiq thing? I presume its a way of interfacing with the GPU?

[jamesh]

Yes, its the interface with the GPU. A very high speed message passing interface type of thing.

Just assume that the calls you make via VCHIQ work fine...you really don't want to know about it....

I've been trying to help on the github page and posting up issues where I can so to help myself and others work through what needs to be done. It's important to note that there doesn't seem to be anything wrong with the hardware at all, which is wonderful to see for a new system like this! It is just how it is plumbed into the linux system through systems like ALSA and X that needs work.

There are a few major bugs to fix, as certain types of usage can cause the module to hang and like many of the people here, I don't want someone who's trying to learn using the Pi to have to worry unduly about low-level trouble.

I'm using mplayer as my key 'troublemaker' at the moment, as that seems to trigger hangs more regularly than most. Simpler players which send audio out without trying to query or change things seem to work fine through the current ALSA driver.

ALSA isn't a pleasant system to build drivers for or even use as a client which makes writing a good driver difficult. The current driver is out there, open sourced, and ready for people to help with.

Even if you don't know how to code, filing good bug reports on where you found problems helps immensely - steps to repeat the error, what version/distro you are using, and so on.

So just to try to get up to speed on this, is the current bug(s) that the alsa interface code is causing a hang/kernel panic?  Is it just when mplayer is sending silence or are other situations causing it?

Are the bug reports published somewhere? I've looked at issues under git and can see squat.

[dom]

drdevil44 said:

So just to try to get up to speed on this, is the current bug(s) that the alsa interface code is causing a hang/kernel panic?  Is it just when mplayer is sending silence or are other situations causing it?

Are the bug reports published somewhere? I've looked at issues under git and can see squat.

The bugs are posted as issues on the firmware tree of guthub. e.g.
https://github.com/raspberrypi/firmware/issues/2

https://github.com/raspberrypi/firmware/issues/6

I think the kernel panic is fixed.

mplayer sends silence presumably because it thinks we are underrunning (however if I just ignore the silence calls the audio sounds fine, and the CPU remains low). My guess is the callbacks that update the read pointer are not as expected.

You sometimes get stalls (that need a control-c) when running mplayer.

Changing volume rapidly whilst audio is playing can cause polayback to freeze.

Yes, I'm pretty sure the kernel panic has gone away

One setting that seems to affect whether mplayer (or any other complex player) will hang is the flag used in sound/arm/bcm2835-vchiq.c: bcm2835_audio_write line 767 onwards.

success = vchi_bulk_queue_transmit(instance->vchi_handle[0],
src, count,
0 *
VCHI_FLAGS_BLOCK_UNTIL_QUEUED
+
1 *
VCHI_FLAGS_BLOCK_UNTIL_DATA_READ,
NULL);

Using the VCHI_FLAGS_BLOCK_UNTIL_QUEUED flag instead, I was unable to get mplayer to hang, and it merrily played on, but the audio was warbling and poor.

Turning the VCHI_FLAGS_BLOCK_UNTIL_DATA_READ flag back on instead gets clear audio playback, but the process still hangs on occassion. I've found that suspending the process (Ctrl-Z SIGUSER) and foregrounding it will often start mplayer going again.

The volume change hang is similar, but the audio often resumes once the volume control process is halted.

A note on debugging – with the verbose debug settings on for the module, the log process takes the lion's share of CPU time BUT mplayer doesn't hang even with the blocking flag used! Certainly some sort of timing issue

updated: just to be clear, I don't think that the conflict happens at that point in the code, just that the extra time spent there on a (I assume) longer wait helps surface the bug

[abishur]

Do you need to do any of this with the latest debian build?  I know they were saying the beta alsa drivers were there, but do you need to do anything other than what post#2 said to activate them?

I'm using the debian build from 13-4-2012.  As someone new to linux, once I've downloaded the new driver and start.elf, are the following commands enough to get the new driver working (temporarily)

rmmod snd-bcm2835

insmod /path/to/driver/snd-bcm2835.ko

?

Do I then need to modprobe afterwards? Or is there something else I missed? I tried the above last night and got seg faults and hanging when I tried to play a .wav file

Thanks

using both start.elf and snd-bcm2835.ko from github on the latest Debian image I have audio over HDMI and audio out! I'm using mpg123 to play some mp3's.

Use modprobe rather than insmod - I think it takes care of dependancies.

I too have output from mplayer but it stalls.

The demos in /opt/vc/src work but you first have to run

/opt/vc/sbin/vcfiled

Just trying to get OMX player to compile but its an arse!

This one seems targetted at rasp-pi - should allow high def vid playing - first to get it to compile please upload binaries

https://github.com/huceke/omxplayer