Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
James Courtier-Dutton <[EMAIL PROTECTED]>: > 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
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 >[EMAIL PROTECTED] >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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
