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@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |