Re: how do you people debug ALSA?

["Clemens Ladisch" <cladisch@fastmail.net>]

mazarick@bellsouth.net wrote:
> It would be fine to say "vi is the development environment,

Actually, I'm using vim.

> and we sprinkle the code with printk statements and take them out when
> the soup's done".

When using snd_printd() or snd_printdd(), one doesn't need to take them
out afterwards. :)

> 1.   Do you regularly use the "alsasound" kernel function during
> development so you can take the driver in and out of the kernel?

I regularly (un)load the modules that I'm changing.  In most cases I
don't use the script that came with my distribution because I don't want
to (un)load all the other sound drivers, too.

> 3.   Are there tools that are almost always used when writing a sound
> card driver like gdb, ddd, etc?

These debuggers don't work with kernel code.

> 4.   Since it's easy to do, is an interface into the proc file system
> useful from the start?

Yes.  Most drivers have some proc file that dumps the current register
contents.  It's always helpful to be able to check what your code did to
the chip.

> 1.  We've having difficulty getting the Altera PLD to load.

This code in uart_gl824_program_pld looks very suspicious:

        //YUCK: This stops us from actually doing it.
        if( uart_io_port != NULL ){
                return(0);
        }

> 2.  Should the 'load the Altera' function be part of the alsa driver,
> part of alsa firmware, or should we just load it up when the computer
> boots (not in alsa)?

Doing it in the driver is easiest (otherwise you would have to write
another kernel module) and ensures that it's actually done before using
the driver.


HTH
Clemens