how do you people debug ALSA?

how do you people debug ALSA?

[Mihaela Vitalariu]

Hello everyone!

How do you ALSA developers debug the ALSA code?
I am working on a large Linux project and i am using gdb which is not very
helpful sometimes.
I also use KDevelop to do graphical debugging(its' debugger is a frontend
for gdb too), but it's not so good for multithreaded programs.

If you have any hints please reply.

Have a nice day!

Re: how do you people debug ALSA?

[Jan-Benedict Glaw]

[-- Attachment #1.1: Type: text/plain, Size: 749 bytes --]

On Mon, 2008-01-21 11:11:25 +0200, Mihaela Vitalariu <admiralwolverine@gmail.com> wrote:
> 
> How do you ALSA developers debug the ALSA code?

Which part of it?  ALSA is a quite large project, starting with kernel
code at the lowest level and ending at application level on the other
end.

> If you have any hints please reply.

What specifically doesn't work?  The question above is far from being
detailed enough to help you. It's like "My car is broken, how do I fix
it?" without any comment which kind of problem you face (engine,
wheels, ...)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
 Signature of:                      http://perl.plover.com/Questions.html
 the second  :

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: how do you people debug ALSA?

[Mihaela Vitalariu]

I meant what tools do you use, what Debuggers?
In my post i wasn't complaining about ALSA, i was just curios about the
debugging tools that you use, from a developer's standpoint...


On Jan 21, 2008 2:04 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:

> On Mon, 2008-01-21 11:11:25 +0200, Mihaela Vitalariu <
> admiralwolverine@gmail.com> wrote:
> >
> > How do you ALSA developers debug the ALSA code?
>
> Which part of it?  ALSA is a quite large project, starting with kernel
> code at the lowest level and ending at application level on the other
> end.
>
> > If you have any hints please reply.
>
> What specifically doesn't work?  The question above is far from being
> detailed enough to help you. It's like "My car is broken, how do I fix
> it?" without any comment which kind of problem you face (engine,
> wheels, ...)
>
> MfG, JBG
>
> --
>      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
>  Signature of:                      http://perl.plover.com/Questions.html
>  the second  :
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHlIo1Hb1edYOZ4bsRArVDAJ9y99DJqrmrmSclUyYsdV2BN8ORDgCeM9te
> mHgH/bxHMhhdSKX9j620xhI=
> =7UKl
> -----END PGP SIGNATURE-----
>
>

Re: how do you people debug ALSA?

[Timur Tabi]

Mihaela Vitalariu wrote:
> Hello everyone!
> 
> How do you ALSA developers debug the ALSA code?

printk().

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: how do you people debug ALSA?

[John Utz]

On Mon, 21 Jan 2008 09:39:51 -0600
"Timur Tabi" <timur@freescale.com> wrote:

> Mihaela Vitalariu wrote:
> > Hello everyone!
> > 
> > How do you ALSA developers debug the ALSA code?
> 
> printk().
> 

yup, gdb and printk. sound device development is relatively challenging
work

Re: how do you people debug ALSA?

[mazarick]

"Mihaela Vitalariu" <admiralwolverine@gmail.com> wrote:

> I meant what tools do you use, what Debuggers?
> In my post i wasn't complaining about ALSA, i was just curios about the
> debugging tools that you use, from a developer's standpoint...

The group that I'm working with (to develop an alsa driver for the Gadget Labs soundcard) would
be very interested in any input on this subject.   The team is made up of skilled C/C++ coders, but
there is very little to no experience with writing a linux hardware driver.

It would be fine to say "vi is the development environment, and we sprinkle the code with printk statements and take them out when the soup's done".   It would save us a lot of overhead in figuring out the best way to get on the same page with each other since it's a pretty new team.  Any other words of wisdom 
from those who've been there would be very welcomed and appreciated.  If you use KDE, Eclipse, or 
something else, that's fine too.

Some particular questions (in no particular order):
1.   Do you regularly use the "alsasound" kernel function during development so you can take the driver
in and out of the kernel?   If it's used, is is used from the beginning or in the last stages of development?
(I'm not sure if it's alsasound, sndconfig, etc).

2.  Are the process statements given in the 'How-To' (snd_printk, snd_assert, snd_BUG) the main ones
or are there others that are 'pre-built' and widely useful?
http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1696.htm

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

4.   Since it's easy to do, is an interface into the proc file system useful from the start?
http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1493.htm

5.   Is the alsa wiki on debugging the sum total of what's needed or is there more we don't know about?
(and we don't know that much!!)
http://www.alsa-project.org/main/index.php/Driver_Compilation

Of course, I could bring up the current Hot and Burning question we have (they are more important now):

http://wavepro-driver.svn.sourceforge.net/viewvc/wavepro-driver/

1.  We've having difficulty getting the Altera PLD to load. Any suggestions on how to do this, how people
without cards can help, an easy way to know when you are successful, or an incremental approach
to the problem?  

2.  The GL card is powered from an Altera PLD (FPGA) (it has similar function as the Envy ICE chip once it's loaded).   For the card to function at all, the Altera PLD has to be loaded when power is applied 
to the computer.   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)?

3.   We're planning on using FC8/PlanetCCRMA as a 'beta test' environment.   I've just noticed the 
new FC8 specific instructions on how to overcome my many bad habits when fooling around with the
kernel.  I'm putting it here for reference so I don't forget it (like I just did when trying to figure out if it was
alsasound, procsound, or whatever to unload the driver).
http://fedoraproject.org/wiki/Docs/CustomKernel

If you would like to just put your two cents worth in to the very small mailing list (for the next 5 days), send a note to:
 wavepro-driver-developers@lists.sourceforge.net
(in 5 days, you'll have to be subscribed to send a note)

-Mike Mazarick

Re: how do you people debug ALSA?

[Clemens Ladisch]

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

Re: how do you people debug ALSA?

[Claudio Matsuoka]

On Jan 21, 2008 6:25 PM,  <mazarick@bellsouth.net> wrote:

> 2.  The GL card is powered from an Altera PLD (FPGA) (it has similar function as the Envy ICE chip once it's loaded).   For the card to function at all, the Altera PLD has to be loaded when power is applied
> to the computer.   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)?

You could check how the wireless card drivers (e.g. ipw2200) install
their firmware code during module loading. I think it's the most
common instance of firmware loading, I would also investigate the
kernel firmware subsystem to see how it works.

Re: how do you people debug ALSA?

[Takashi Iwai]

Just covering the things that are still missing...

At Mon, 21 Jan 2008 20:25:37 +0000,
mazarick@bellsouth.net wrote:
> 3.   Are there tools that are almost always used when writing a
> sound card driver like gdb, ddd, etc? 

Don't forget strace.  It's quite useful to track down strange behavior
or the driver.

> 4.   Since it's easy to do, is an interface into the proc file
> system useful from the start? 
> http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1493.htm

You can implement a proc write for debugging.  It's useful for
changing the register value on the fly.


Takashi