Some questions about DDK

There are things which DDK docs do not make very clear and even sample
sources do not help.

  1. How to get options (passed in command line or mount command) into
    driver DLL?
  2. Does io-audio handle multiple cards case? If yes there got to be some
    global data structures?
  3. None of supplied driver sources actually support multiple hardware
    subchannels. Do I need to bind the subchannels with mixer somehow? I
    think it is bad that template driver assumes single subchannel only.
  4. There’s no (documented) snd_pcm_mmap() call, but there seem to be
    data structures to handle mmap. Does the framework actually support
    mmap()? There is not even a flag like SNDRV_PCM_INFO_MMAP, how would
    applications know if mmap() is supported? I know that some applications
    require it…
  5. What are plans wrt midi/timer/sequencer stuff? I believe the whole
    point of ALSA was to provide that (and better mixer) functionality since
    it was missed in OSS. Also why /proc/asound is not supported?

TIA,

  • igor

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

  1. How to get options (passed in command line or mount command) into
    driver DLL?

the third arg passed to your init function is a charater
string of all options, use getsubopt or something similar to
process it. This string is usually passed to the
“ado_pci_device()” call so the pci index option can be
processed.

  1. Does io-audio handle multiple cards case? If yes there got to be some
    global data structures?

Yes it does, the implementation is not documented as it
should not be needed by a driver. The dll you write will be
loaded when needed and the init routine called once for
every card. When a card is unmounted the destroy function
will be called and if it is the last card managed by that
dll the dll will be unloaded.


  1. None of supplied driver sources actually support multiple hardware
    subchannels. Do I need to bind the subchannels with mixer somehow? I
    think it is bad that template driver assumes single subchannel only.

Just before the release of the DDK legal issues were found
with every one of our multisubchannel drivers so none were
released in src. We are currently still talking to one
vendor if we get their permision we will release that driver
as a reference, alternatively we’ll write a template.


  1. There’s no (documented) snd_pcm_mmap() call, but there seem to be
    data structures to handle mmap. Does the framework actually support
    mmap()? There is not even a flag like SNDRV_PCM_INFO_MMAP, how would
    applications know if mmap() is supported? I know that some applications
    require it…

“snd_pcm_mmap()” has not been documented because the client
side implementation (patterned after ALSA) is a little
strange, but it will probably remain and be documented in
the future. A driver signals its ability to support a direct
mmap interface with the capability flag
“SND_PCM_CHNINFO_MMAP”. With this flag set the driver just
uses the “ado_shm_alloc” to allocate a shared memory dma
buffer.


  1. What are plans wrt midi/timer/sequencer stuff? I believe the whole
    point of ALSA was to provide that (and better mixer) functionality since
    it was missed in OSS. Also why /proc/asound is not supported?

Long term plans are to examine midi, but no timetable has
been set yet. The “proc/asound” interface was not
implemented when the architecture was re implemented because
it was not needed by any standard applications and seemed to
be very driver specific.

Audio Support wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

  1. How to get options (passed in command line or mount command) into
    driver DLL?

the third arg passed to your init function is a charater
string of all options, use getsubopt or something similar to
process it. This string is usually passed to the
“ado_pci_device()” call so the pci index option can be
processed.

The template seems to be passing it to ado_pci_device ‘as is’ which is
very confusing. Does ao_pci_device() parse the options? What is list of
recognized options then?

  1. Does io-audio handle multiple cards case? If yes there got to be some
    global data structures?

Yes it does, the implementation is not documented as it
should not be needed by a driver. The dll you write will be
loaded when needed and the init routine called once for
every card. When a card is unmounted the destroy function
will be called and if it is the last card managed by that
dll the dll will be unloaded.

I don’t quite get it. The init routine must look for PCI device using
VID and DID. If I have multiple cards all supported by single driver,
how do I know for which one to look each time init is called? And if
cards are the same, init must be invoked with different ‘pci’ option?
Who takes care of that?

  1. There’s no (documented) snd_pcm_mmap() call, but there seem to be
    data structures to handle mmap. Does the framework actually support
    mmap()? There is not even a flag like SNDRV_PCM_INFO_MMAP, how would
    applications know if mmap() is supported? I know that some applications
    require it…

“snd_pcm_mmap()” has not been documented because the client
side implementation (patterned after ALSA) is a little
strange, but it will probably remain and be documented in
the future. A driver signals its ability to support a direct
mmap interface with the capability flag
“SND_PCM_CHNINFO_MMAP”. With this flag set the driver just
uses the “ado_shm_alloc” to allocate a shared memory dma
buffer.

Do I have to do anything in the driver to support mmap()?

  1. What are plans wrt midi/timer/sequencer stuff? I believe the whole
    point of ALSA was to provide that (and better mixer) functionality since
    it was missed in OSS. Also why /proc/asound is not supported?

Long term plans are to examine midi, but no timetable has
been set yet.

It would not be too hard to let io-audio to create all standard ALSA
devices in /dev/snd and leave implementation to driver writers. As of
now I simply can not support midi even if I wanted to. Unless I turn my
driver into resmgr, or course…

  • Igor

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

The template seems to be passing it to ado_pci_device ‘as is’ which is
very confusing. Does ao_pci_device() parse the options? What is list of
recognized options then?

Yes, ado_pci_device does parse out some options. Currently, the only option
that it parses is ‘pci’ which allows the user to specify a particular pci
index to attach the driver to. It is intended that you parse it (using
getsubopt for example) for your options, then pass the string on to the
ado_pci_device call, so that it can parse for its options.

  1. Does io-audio handle multiple cards case? If yes there got to be
    some global data structures?

Yes it does, the implementation is not documented as it
should not be needed by a driver. The dll you write will be
loaded when needed and the init routine called once for
every card. When a card is unmounted the destroy function
will be called and if it is the last card managed by that
dll the dll will be unloaded.

I don’t quite get it. The init routine must look for PCI device using
VID and DID. If I have multiple cards all supported by single driver,
how do I know for which one to look each time init is called? And if
cards are the same, init must be invoked with different ‘pci’ option?
Who takes care of that?

You don’t know. No, there is no requirement to use the pci option. Just
hunt through all possible VID/DID cases in an arbitrary order.

Each iteration of the dll that is loaded only supports one physical piece
of hardware. Therefore, if you have two cards, you will have two deva dlls
loaded even if they are the same dll. The technique that we are using to
attach to the PCI server automatically removes the device from the
available pool of devices.
Have your driver hunt through all its possible device and vendor ids
until it finds a single match, then stop looking. If there are any other
cards, they will be picked up by subsequent iterations of the driver dll.

Here’s a little example of what I mean:

if (((my_card->pci =
ado_pci_device (PCI_VENDOR_ID_MY_CARD, PCI_DEVICE_ID_1, args)) != NULL)
|| ((my_card->pci =
ado_pci_device (PCI_VENDOR_ID_MY_CARD, PCI_DEVICE_ID_2, args)) != NULL))
{
ado_card_set_shortname (card, “My Card”);
ado_card_set_longname (card, “My Card”, my_card->pci->iobase[0]);
}
else
{
ado_error (“Unable to detect PCI device (%s)\n”, strerror (errno));
ado_free (my_card);
return -1;
}

  1. There’s no (documented) snd_pcm_mmap() call, but there seem to be
    data structures to handle mmap. Does the framework actually support
    mmap()? There is not even a flag like SNDRV_PCM_INFO_MMAP, how would
    applications know if mmap() is supported? I know that some
    applications require it…

“snd_pcm_mmap()” has not been documented because the client
side implementation (patterned after ALSA) is a little
strange, but it will probably remain and be documented in
the future. A driver signals its ability to support a direct
mmap interface with the capability flag
“SND_PCM_CHNINFO_MMAP”. With this flag set the driver just
uses the “ado_shm_alloc” to allocate a shared memory dma
buffer.

Do I have to do anything in the driver to support mmap()?

Just make sure that the SND_PCM_CHNINFO_MMAP capability flag is set.
That is all that is required. Nice and simple. :slight_smile:

  1. What are plans wrt midi/timer/sequencer stuff? I believe the whole
    point of ALSA was to provide that (and better mixer) functionality
    since it was missed in OSS. Also why /proc/asound is not supported?

Long term plans are to examine midi, but no timetable has
been set yet.

It would not be too hard to let io-audio to create all standard ALSA
devices in /dev/snd and leave implementation to driver writers. As of
now I simply can not support midi even if I wanted to. Unless I turn my
driver into resmgr, or course…

Igor, we are not ALSA. That is very important to remember. We didn’t express
that strongly enough in our first few cuts of the audio DDK and SDK. Our
similarities to ALSA seem to have become an impediment to understanding. We
completely reworked the internals to automate/commonize as much of the
driver writing experience as possible. You are 100% correct. You cannot
support MIDI at this time unless you do it all yourself.

Audio Support wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
The template seems to be passing it to ado_pci_device ‘as is’ which is
very confusing. Does ao_pci_device() parse the options? What is list of
recognized options then?

Yes, ado_pci_device does parse out some options. Currently, the only option
that it parses is ‘pci’ which allows the user to specify a particular pci
index to attach the driver to. It is intended that you parse it (using
getsubopt for example) for your options, then pass the string on to the
ado_pci_device call, so that it can parse for its options.

ok, understood.

Have your driver hunt through all its possible device and vendor ids
until it finds a single match, then stop looking. If there are any other
cards, they will be picked up by subsequent iterations of the driver dll.

Thanks, that is clear now. By ‘technique we use to attach to PCI
devices’ you mean ado_pci_device(), right? I don’t think standard
pci_attach_device() call provides that feature. This really should be
explained in the DDK docs.

“snd_pcm_mmap()” has not been documented because the client
side implementation (patterned after ALSA) is a little
strange, but it will probably remain and be documented in
the future. A driver signals its ability to support a direct
mmap interface with the capability flag
“SND_PCM_CHNINFO_MMAP”. With this flag set the driver just
uses the “ado_shm_alloc” to allocate a shared memory dma
buffer.

Do I have to do anything in the driver to support mmap()?

Just make sure that the SND_PCM_CHNINFO_MMAP capability flag is set.
That is all that is required. Nice and simple. > :slight_smile:

I’m concerned because my case appear to be complicated. All drivers in
the DDK appear to allocate/free separate DMA buffer every time
aquire/release is called, i.e., for every subchannel. I’m suspecting
that mmap() support might depend on that behavior.

It can’t work that way in Maestro driver, because all memory blocks must
be within 4Mb of each other, so driver allocates single buffer in the
init() and manages chunks of memory inside it. Would that be a problem?
I just need clear understanding of what io-audio really does to support
mmap(). In particular, what do you use ‘name’ of DMA buffer for? If it
is used to identify memory block mapped by driver to mmap() it into user
app, that probably would be a problem indeed, since I don’t have
suitable ‘name’ for every chunk of memory.

Igor, we are not ALSA. That is very important to remember. We didn’t express
that strongly enough in our first few cuts of the audio DDK and SDK. Our
similarities to ALSA seem to have become an impediment to understanding. We
completely reworked the internals to automate/commonize as much of the
driver writing experience as possible. You are 100% correct. You cannot
support MIDI at this time unless you do it all yourself.

Yes, DDK part is not ALSA, but SDK has ALSA-compatible interface, more
or less. You are free to implement internals in whatever way you like,
but client interface must be as compatible with ALSA as possible,
otherwise it will all be an excercise in futility. That means if ALSA
client interface includes MIDI/sequencer/timers then your DDK in one way
or another should provide at least theoretical capability to support
those.

I did not ask you to follow ALSA drivers implementation. What I suggest
is to make the DDK flexible enough to allow driver writers to add
functionality missing in the framework. Is that too much to ask? ALSA
does not provide all possible devices for all possible cards either, but
they do have concept of ‘hardware dependent device’ so particular
drivers may choose to create and handle specific devices. If you had
something similar, it would allow to treat MIDI as ‘hardware dependent
device’ for now, until you make up your mind about supporting it.

Thanks,

  • Igor