I'll keep this simple... I am pretty much new to Linux generally (bar using Ubuntu sometimes and some basic terminal knowledge) and was hoping someone would be willing to write up the process to get audio working on my EFIKA.

I have a nice, newly-completed Debian install from using the DI_EFIKA installer. The only things I have installed so far are xfce/blackbox, and VLC (which obviously lacks sound).

Is anyone willing to write out the steps for me that I would need just to get basic audio out working..?
Thanks in advance to anyone who can.

Unfortunately, as far as i know, there's no really easy way for that ATM. You need to get sources of some specific kernel versions (from kernel.org), patch it with a patchset, then configure and build it yourself... It's really not a job i'd recommend for a Linux beginner on an Efika-level hardware.

But if someone knows an already built Debian kernel package for the Efika, using the latest patchset, somewhere on the net, i'd be most happy to admit that i was proven wrong. :)

Since I'm using gentoo and not debian I don't have a debian kernel for you. But I do have a tarball with patches for the 2.6.22 kernel. If you want you can try the kernel I build using that. Tarball (kernel+modules) here.

Thanks, this is all much appreciated. I may well give the kernel and modules a try later on and hope for the best.

Question: Do your patch pack support DMA sound already, or it's still pio only? I heard that someone wrote at least a basic DMA sound driver, but i haven't tried to get it, or install it until now. I'm just wondering if it's included in the patchset you linked.

It contains this sound patch. There is dma stuff in there, so I'd say it supports dma. But I could be wrong...

I just found time to try it out, and it seems it indeed works with DMA. No more scratchy noises, jumps and clicks when accessing disk, or other peripherials. Cool. :) Thanks for linking the patchset!

Times like this I wish I had a clue what I was doing! ;)

Yeah it is a little better however if you check the driver, it does 32-bit sample transfers over the AC97 bus (and only reports supporting these).

This means all your audio data has to be upsampled to 32-bit before being transferred (by ALSA, however this is so efficient anyway to do).. there may be a small CPU penalty even though you're using DMA.

I have a small question for you guys; does anyone want to sit down and improve the BestComm driver and DMA routines so that they use the firmware tasks rather than loading them from Linux?

Some of the code is already in there, albeit commented out. All you need to do is look for the device tree entry the driver probes for, and get it's bestcomm-task (or bestcomm-rx-task or bestcomm-tx-task depending on the capability) and set up from there accordingly.

_________________
Matt Sealey

Well, processing ~400K of data per sec shouldn't hurt that much. Still it should be optimized, but there are much worse bottlenecks and CPU hoggers inside (ie. look at X, some of the drivers, or some of the GUI kits)...
What's the advantage of using the firmware rather than abusing the DMA directly, especially if direct DMA already works, just needs a bit more work to get it finalized?

if you have (as me) make a fresh debian install for efika (with di_efika), after you have no sound and alsaconf find no sound card.

To active sound I made the following things :
- download the precompiled (+sound) modules from bplan : http://www.efika.de/download/modules_ef ... ndbeta.tgz
- put the content on / (as root logging). It creates a folder called "2.6.19-rc6-g9468d500-dirty" with files in it under /lib/modules
- as root, type the command : devmod -v
- then type : modprobe snd-mpc52xx-ac97
- now the sound is actived (try xmms or vlc to test)
- in /etc , you will find a file called modules (create it if not present)
- simply add the line : snd-mpc52xx-ac97 in /etc/modules . It enables the sound each time you reboot.

best
Bruno

It could make the difference between smooth audio and audible pops and clicks even under moderate system load.

One thing to consider is the user experience - not only if the system is being used most efficiently but what parts of the system would become most annoying if they were not.

Audio is something you would notice far, far more (clicks and pops and breaks in music) than a slightly blocky video or some extraneous redraw in X. You might notice most media players - intentionally or otherwise - will spend more effort resynchronising audio and keeping it smooth than rendering every frame of a video (since 22 frames out of 24 isn't that noticable, but even a 1/50 of a second of missing audio is VERY noticable).

The audio driver isn't currently capable of high quality playback without skips and pops under moderate load, so this is something to fix. I have no qualms whatsoever with the quality of the Radeon X.org driver in comparison :D

_________________
Matt Sealey