Migration from 0.5 to 0.9?

Migration from 0.5 to 0.9?

[Leif Lindholm]

Hello

I'm working on a set-top-box based on the National Semiconductor SC1200
Geode integrated microprocessor.

National have been nice enough to write an Alsa-driver for the built-in
AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b.

So now I need to modify this one to use with 0.9.

Can someone give me a few tips/hints or is there possibly a document
about this that I failed to google up?

regards
	/
		Leif

Re: Migration from 0.5 to 0.9?

[James Courtier-Dutton]

Leif Lindholm wrote:

>Hello
>
>I'm working on a set-top-box based on the National Semiconductor SC1200
>Geode integrated microprocessor.
>
>National have been nice enough to write an Alsa-driver for the built-in
>AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b.
>
>So now I need to modify this one to use with 0.9.
>
>Can someone give me a few tips/hints or is there possibly a document
>about this that I failed to google up?
>
>regards
>	/
>		Leif
>
>
>
>
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
I would post the source code of your current driver somewhere (URL).
If the set top box uses the AC97-Controller, alsa09 might already have a 
sound driver for it, but someone might need to add an extra bit of card 
recognition code to get it to work.
Also, if you can post to a URL any documents about the set-top-box, 
which would make it easier for people to help you. We might be able to 
recognise which of the current drivers is closest to it from that.
It would probably be better to get support for the set top box into the 
publically available version of alsa09, so that it will be kept up to 
date with any other changes which might happen in alsa without you 
having to worry about it.

Cheers
James

Re: Migration from 0.5 to 0.9?

[Leif Lindholm]

On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote:
> I would post the source code of your current driver somewhere (URL).

If you still think so after reading this mail (especially license stuff
at end of mail), I could post a diff somewehere.

> If the set top box uses the AC97-Controller, alsa09 might already have a 
> sound driver for it, but someone might need to add an extra bit of card 
> recognition code to get it to work.

It uses the internal AC97-controller of the SC1200 processor
(XpressAUDIO - PCI device 100b:0503). I didn't find anything like that
in the 0.9 code when I browsed through it. The driver also incorporates
some MIDI stuff and such.

> Also, if you can post to a URL any documents about the set-top-box, 
> which would make it easier for people to help you. We might be able to 
> recognise which of the current drivers is closest to it from that.

Well - I'm _paid_ to write these drivers :)

National puts "Confidential" notices on all their documentation, so I
don't think it would be a good idea to post those...

And since our box is not quite on the market yet, I think my managers
might not like me releasing too much specs.

So what I can say is about this:

The audio controller is described pretty well in this message I located
on google:
http://www.alsa-project.org/archive/alsa-howto/msg00312.html

Different revisions of the box use CS4299 or CS4205 codecs.

> It would probably be better to get support for the set top box into the 
> publically available version of alsa09, so that it will be kept up to 
> date with any other changes which might happen in alsa without you 
> having to worry about it.

I definitely agree with you about this, however Nationals driver has
some weird "BSD with export restrictions" license attached to it.

Personally I think they should release the code under GPL so that it can
be integrated with the main project, and I will try to convince them to
do so - but for now I simply don't have time to wait for that.

To clarify myself: what I really need right now is some hints about what
differs between 0.5 and 0.9 from the driver(programmer)s point of view.

regards
	/
		Leif

Re: Migration from 0.5 to 0.9?

[James Courtier-Dutton]

Leif Lindholm wrote:

>On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote:
>
>>I would post the source code of your current driver somewhere (URL).
>>
>
>If you still think so after reading this mail (especially license stuff
>at end of mail), I could post a diff somewehere.
>
>>If the set top box uses the AC97-Controller, alsa09 might already have a 
>>sound driver for it, but someone might need to add an extra bit of card 
>>recognition code to get it to work.
>>
>
>It uses the internal AC97-controller of the SC1200 processor
>(XpressAUDIO - PCI device 100b:0503). I didn't find anything like that
>in the 0.9 code when I browsed through it. The driver also incorporates
>some MIDI stuff and such.
>
>>Also, if you can post to a URL any documents about the set-top-box, 
>>which would make it easier for people to help you. We might be able to 
>>recognise which of the current drivers is closest to it from that.
>>
>
>Well - I'm _paid_ to write these drivers :)
>
>National puts "Confidential" notices on all their documentation, so I
>don't think it would be a good idea to post those...
>
>And since our box is not quite on the market yet, I think my managers
>might not like me releasing too much specs.
>
>So what I can say is about this:
>
>The audio controller is described pretty well in this message I located
>on google:
>http://www.alsa-project.org/archive/alsa-howto/msg00312.html
>
>Different revisions of the box use CS4299 or CS4205 codecs.
>
>>It would probably be better to get support for the set top box into the 
>>publically available version of alsa09, so that it will be kept up to 
>>date with any other changes which might happen in alsa without you 
>>having to worry about it.
>>
>
>I definitely agree with you about this, however Nationals driver has
>some weird "BSD with export restrictions" license attached to it.
>
>Personally I think they should release the code under GPL so that it can
>be integrated with the main project, and I will try to convince them to
>do so - but for now I simply don't have time to wait for that.
>
>To clarify myself: what I really need right now is some hints about what
>differs between 0.5 and 0.9 from the driver(programmer)s point of view.
>
>regards
>	/
>		Leif
>
>
I guess you might be out of luck then, as there is currently no 
documentation on how to write sound card drivers for alsa09.

I think the only way you can possibly compare alsa05 with alsa09 at the 
moment, is pick simple sound card like the sb16, and compare the card's 
source code in alsa05 and alsa09.

Cheers
James

Re: Migration from 0.5 to 0.9?

[Eric Dantan Rzewnicki]

James Courtier-Dutton wrote:
> 
> Leif Lindholm wrote:
> 
> >On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote:

> I guess you might be out of luck then, as there is currently no
> documentation on how to write sound card drivers for alsa09.
> 
> I think the only way you can possibly compare alsa05 with alsa09 at the
> moment, is pick simple sound card like the sb16, and compare the card's
> source code in alsa05 and alsa09.
> 
> Cheers
> James

I know this information is about writing an alsa client and not a
driver....
But, perhaps Mark Rages', Matthias Nagorni's and Paul Davis's pages on
writing clients with the alsa library would be helpful in some way:
http://mlug.missouri.edu/~markrages/wiki/index.php?WritingAnAlsaClient

The later two are linked to from the first.

I appologize if this isn't helpful.

-Eric Rz.

Re: Migration from 0.5 to 0.9?

[James Courtier-Dutton]

Eric Dantan Rzewnicki wrote:

>James Courtier-Dutton wrote:
>
>>Leif Lindholm wrote:
>>
>>>On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote:
>>>
>
>>I guess you might be out of luck then, as there is currently no
>>documentation on how to write sound card drivers for alsa09.
>>
>>I think the only way you can possibly compare alsa05 with alsa09 at the
>>moment, is pick simple sound card like the sb16, and compare the card's
>>source code in alsa05 and alsa09.
>>
>>Cheers
>>James
>>
>
>I know this information is about writing an alsa client and not a
>driver....
>But, perhaps Mark Rages', Matthias Nagorni's and Paul Davis's pages on
>writing clients with the alsa library would be helpful in some way:
>http://mlug.missouri.edu/~markrages/wiki/index.php?WritingAnAlsaClient
>
>The later two are linked to from the first.
>
>I appologize if this isn't helpful.
>
>-Eric Rz.
>
I think Leif was asking how to write drivers for the sound hardware 
device to alsa-lib interface(i.e. What alsa-driver/alsa-kernel does) and 
not the application to alsa-lib interface.
Maybe I will write some documentation when i attempt to write a new 
hardware driver myself. I am thinking of writing one for the dxr3 mpeg2 
decoder board, which has a simple audio out jack on it, which currently 
only have oss support.

Cheers
James

Re: Migration from 0.5 to 0.9?

[leif.lindholm]

James Courtier-Dutton <James@superbug.demon.co.uk>:
> I guess you might be out of luck then, as there is currently no 
> documentation on how to write sound card drivers for alsa09.
> 
> I think the only way you can possibly compare alsa05 with alsa09 at the
> moment, is pick simple sound card like the sb16, and compare the card's
> source code in alsa05 and alsa09.

Well, that was plan B :]

I'll try to make some notes about it in case someone else find themselves in a 
similar situation.

regards
    /
        Leif

Re: Migration from 0.5 to 0.9?

[Takashi Iwai]

At 04 Apr 2002 15:41:36 +0200,
Leif Lindholm wrote:
> 
> Hello
> 
> I'm working on a set-top-box based on the National Semiconductor SC1200
> Geode integrated microprocessor.
> 
> National have been nice enough to write an Alsa-driver for the built-in
> AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b.
> 
> So now I need to modify this one to use with 0.9.
> 
> Can someone give me a few tips/hints or is there possibly a document
> about this that I failed to google up?

unfortunatley (as always :) there is no documentation about the kernel
stuff yet.
since you have already a working 0.5.x driver, it's not too difficult,
though. 

as far as i can remember..

- renaming

	fragment -> period
	channel -> stream
	voice -> channel
	snd_pcm_subchannel -> snd_pcm_substream

- renaming of constants

	generally:
		SND_XXX -> SNDRV_XXX

	some other changes, too: e.g.
		SND_PCM_TRIGGER_GO -> SNDDRV_PCM_TRIGGER_START

- snd_assert() is used instead of snd_debug_check()
  (note that the argument is opposite, assert(x) means that "x" is true .)

- no longer difference of stream/blocking modes

- general hardware information is stored in snd_pcm_hardware_t
  and passed to the runtime struct in open().
  the information is intuitive, look at other sources.

- abstracted ops.

	open(substream)
		- open the device
		- copy the substream->runtime->hw parameter
		  (not pass the pointer)
		- set up the constraints (if any)

	hw_params(substream, hw_params)
		- allocate a buffer
		  usually via snd_pcm_lib_malloc_pages

	prepare(substream)
		- set up the hardware parameters (like 0.5.x)

		  note that parameters in runtime struct are
		  stored in frames, not in bytes.
		  there are functions, snd_pcm_lib_buffer_bytes()
		  and snd_pcm_lib_period_bytes()

	trigger(substream, cmd)
		- start, stop, pause (like 0.5.x)

	pointer(substream)
		- returns the current pointer where the hw refers.
		  (in frames!)

	hw_free(substream)
		- free the buffer
		  usually via snd_pcm_lib_free_pages(substream)

	close(substream)
		- close the device, clean up.

	copy, silence
		- needed only if you don't (can't) use mmap.

  they are defiend in snd_pcm_ops_t struct and set up in
  pcm initizliation routine via snd_pcm_set_ops().

- when the interrupt occurs at period (fragment), call

	snd_pcm_period_elapsed(substream)

  just once per interrupt.

- no longer snd-xxx functions for allocating port, dma and irqs.
  you need to use standard functions.
  for releasing struct resources *, you have to use kfree_nocheck()
  to avoid malloc-wrapper.

- definitions of pci id table, probe(), remove() (suspend() and
  remove() if possible) on struct pci_driver.
  
- finally and best way - look at drivers on a same chip of both 0.5.x
  and 0.9.0, and compare them :)



Takashi

Re: Migration from 0.5 to 0.9?

[James Courtier-Dutton]

Takashi Iwai wrote:

>At 04 Apr 2002 15:41:36 +0200,
>Leif Lindholm wrote:
>
>>Hello
>>
>>I'm working on a set-top-box based on the National Semiconductor SC1200
>>Geode integrated microprocessor.
>>
>>National have been nice enough to write an Alsa-driver for the built-in
>>AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b.
>>
>>So now I need to modify this one to use with 0.9.
>>
>>Can someone give me a few tips/hints or is there possibly a document
>>about this that I failed to google up?
>>
>
>unfortunatley (as always :) there is no documentation about the kernel
>stuff yet.
>since you have already a working 0.5.x driver, it's not too difficult,
>though. 
>
>as far as i can remember..
>
>- renaming
>
>	fragment -> period
>	channel -> stream
>	voice -> channel
>	snd_pcm_subchannel -> snd_pcm_substream
>
>- renaming of constants
>
>	generally:
>		SND_XXX -> SNDRV_XXX
>
>	some other changes, too: e.g.
>		SND_PCM_TRIGGER_GO -> SNDDRV_PCM_TRIGGER_START
>
>- snd_assert() is used instead of snd_debug_check()
>  (note that the argument is opposite, assert(x) means that "x" is true .)
>
>- no longer difference of stream/blocking modes
>
>- general hardware information is stored in snd_pcm_hardware_t
>  and passed to the runtime struct in open().
>  the information is intuitive, look at other sources.
>
>- abstracted ops.
>
>	open(substream)
>		- open the device
>		- copy the substream->runtime->hw parameter
>		  (not pass the pointer)
>		- set up the constraints (if any)
>
>	hw_params(substream, hw_params)
>		- allocate a buffer
>		  usually via snd_pcm_lib_malloc_pages
>
>	prepare(substream)
>		- set up the hardware parameters (like 0.5.x)
>
>		  note that parameters in runtime struct are
>		  stored in frames, not in bytes.
>		  there are functions, snd_pcm_lib_buffer_bytes()
>		  and snd_pcm_lib_period_bytes()
>
>	trigger(substream, cmd)
>		- start, stop, pause (like 0.5.x)
>
>	pointer(substream)
>		- returns the current pointer where the hw refers.
>		  (in frames!)
>
>	hw_free(substream)
>		- free the buffer
>		  usually via snd_pcm_lib_free_pages(substream)
>
>	close(substream)
>		- close the device, clean up.
>
>	copy, silence
>		- needed only if you don't (can't) use mmap.
>
>  they are defiend in snd_pcm_ops_t struct and set up in
>  pcm initizliation routine via snd_pcm_set_ops().
>
>- when the interrupt occurs at period (fragment), call
>
>	snd_pcm_period_elapsed(substream)
>
>  just once per interrupt.
>
>- no longer snd-xxx functions for allocating port, dma and irqs.
>  you need to use standard functions.
>  for releasing struct resources *, you have to use kfree_nocheck()
>  to avoid malloc-wrapper.
>
>- definitions of pci id table, probe(), remove() (suspend() and
>  remove() if possible) on struct pci_driver.
>  
>- finally and best way - look at drivers on a same chip of both 0.5.x
>  and 0.9.0, and compare them :)
>
>
>
>Takashi
>
This is a very good start at some documentation!

In case Leif does not understand the concept of a frame, here is what I 
understand by it.

Audio stream is 16 bit samples, 2 channels = 4 bytes (2 bytes of each 
sample, and 2 channel=2*2) = 1 frame
Audio stream is 16 bit samples, 6 channels = 12 bytes = 1 frame
Audio stream is 8 bit samples, 2 channels = 2 bytes = 1 frame

So, no matter what the sample bits, or number of channels, there is 
always 1 frame.
If the stream is 48000 Hz, it will contain 48000 frames.
If the stream is 44100 Hz, it will contain 44100 frames.

If the stream is 48000 Hz, 16 bit samples, 6 channels 5.1(surround) 
audio, it will contain 48000 frames.

Hopefully, by these examples, you get an idea of what a frame is.

Cheers
James

Re: Migration from 0.5 to 0.9?

[Takashi Iwai]

At 08 Apr 2002 17:09:46 +0200,
Leif Lindholm wrote:
> 
> Thanks a lot for the info!
> 
> This will be most helpful.
> 
> I'm starting to think ens1371 was _not_ the best driver to use for
> comparison :]

for example, maestro3 driver has little difference between 0.5.x and
0.9.0 (because i wrote both versions at the same time :)
you can see what have been renamed there.


Takashi