[PD] PD support for new alsa

[Karl MacMillan]

On Fri, 20 Apr 2001, Winfried Ritsch wrote:

>
>
> Hello,
>
>  > This should work with the alsa cvs version as of a few days ago or the
>  > newest beta available on the alsa website (www.alsa-project.org).  It is
>  > currently limited to 16/24 bit interleaved cards - i.e. no hammerfall.  I
>  > have only tested it on a stereo 16 bit card.  Either Winfried Ritsch or I
>  > will produce an optimized version for the hammerfall soon (still
>  > interested in doing this Winfried?).  Finally, you will probably
>  > need to set the number of frags to make it work at all.  Try this
>  > commandline first:
>
> yes I am on the way, but the alsa-mmap interface was just changed
> again the last days ;-(, even there is one problem, that is you cannot
> allocate a subset of channels in mmap on alsa so always have to use
> all 26 (18) channels, which is not always preferabel. Maybe we just
> should integrate the non-interleaved no-mmap interface also in your
> driver-interface or using "plugin:" for these cases and a special mmap
> one for really low latency for all channels ?
>

Hmmm, I am adding a command line switch right now to allow the user to
choose the plugin layer.  This seems like a good compromise to me - it
will allow the user to choose whether they want performance or
flexibility.

Also, I think I will start separating the perform functions instead of
dumping all possible combinations into 1 long function.  Are there any
objections to using the gcc specific inline keyword in the alsa code?  If
you are using alsa you _must_ be using gcc as far as I know so this seems
safe.

> One other idea is that the driver allocates all channels but fill only
> these which are needed, so an performance improvement could be that
> the adc~/dac~ object reports or are asked in some way if they are
> allocated, so only these channels are copy/converted from/to float
> to/from card-format.
>

This seems like a good idea as well.  Maybe instead of the adc~/dac~ it
can be the number of devices requested on the command line.  This would
require fewer changes in the code and be simplier overall.

>  >
>  > I know this seems like a lot of fragments, but this is comprable latency
>  > to OSS on my machine.  Please test this and tell me how it works or
>  > doesn't work.  Miller, if you would like a diff just let me know.
>  >
>
> ok, the option -noadc and -nodac does a:
> pd: pcm_params.c:2081: snd_pcm_hw_refine: Assertion `pcm && params'
> failed.
>

This is fixed in my local copy.  I will upload another version after I
here from some more people.

Karl

> mfg winfried
>

_____________________________________________________
| Karl W. MacMillan                                 |
| Computer Music Department                         |
| Peabody Institute of the Johns Hopkins University |
| karlmac at peabody.jhu.edu                           |
| www.peabody.jhu.edu/~karlmac                      |
-----------------------------------------------------