[alsa-devel] ALSA driver for Native Instruments sound hardware
Hi, some months after the last posting, we finally managed to finish a new version of the ALSA driver for Native Instruments' external USB sound cards such as "Rig Kontrol 2", "Kore Kontroller", "Audio Kontrol 1" and "Audio 8 DJ". Compared to the last release, the following things were changed: - the streaming logic was completely reworked so that multiple substreams are handled correctly - a Linux input device layer was added to support the knobs, buttons and pedals on "Rig Kontrol 2" and "AudioKontrol 1" - workqueues were entirely removed from the code - most data structures are now allocated within one big struct to avoid multiple, smaller allocations - many more cleanups according to Clemens' reply on my last posting[1] The driver was properly tested with all the mentioned hardware on both record and playback channels. The patchset should apply to the current mecurial alsa-kernel tree. Please let me know what you think. Best regards, Daniel [1] http://article.gmane.org/gmane.linux.alsa.devel/34324/ Signed-off-by: Daniel Mack <daniel@caiaq.org> Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
At Fri, 23 Mar 2007 18:02:11 +0100, Daniel Mack wrote:
diff -Nur alsa-kernel-ni/usb/caiaq/caiaq-audio.c alsa-kernel/usb/caiaq/caiaq-audio.c --- alsa-kernel-ni/usb/caiaq/caiaq-audio.c 1970-01-01 01:00:00.000000000 +0100 +++ alsa-kernel/usb/caiaq/caiaq-audio.c 2007-03-23 17:33:59.000000000 +0100 + +static int snd_usb_caiaq_pcm_trigger(struct snd_pcm_substream *substream, + int cmd) +{ + struct snd_usb_caiaqdev *dev = snd_pcm_substream_chip(substream); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
Put 'case' with the same indent level as switch. (Ditto for all switch blocks in other places.)
diff -Nur alsa-kernel-ni/usb/caiaq/caiaq-device.c alsa-kernel/usb/caiaq/caiaq-device.c --- alsa-kernel-ni/usb/caiaq/caiaq-device.c 1970-01-01 01:00:00.000000000 +0100 +++ alsa-kernel/usb/caiaq/caiaq-device.c 2007-03-23 17:33:59.000000000 +0100 +static void usb_ep1_command_reply_dispatch (struct urb* urb) +{ + int ret; + struct snd_usb_caiaqdev *dev = urb->context; + unsigned char *buf = urb->transfer_buffer; + + if (urb->status || !dev) { + log("%s: received urb->status = %i\n", __FUNCTION__, urb->status); + return; + } + + switch(buf[0]) { + case EP1_CMD_GET_DEVICE_INFO: + { + memcpy(&dev->spec, buf+1, sizeof(struct caiaq_device_spec));
Don't you need to convert 16bit values for big-endian? Also, some lines are too long. Please try to keep lines in 80 chars as much as possible. Thanks, Takashi
On Mon, Mar 26, 2007 at 03:45:47PM +0200, Takashi Iwai wrote:
diff -Nur alsa-kernel-ni/usb/caiaq/caiaq-audio.c alsa-kernel/usb/caiaq/caiaq-audio.c --- alsa-kernel-ni/usb/caiaq/caiaq-audio.c 1970-01-01 01:00:00.000000000 +0100 +++ alsa-kernel/usb/caiaq/caiaq-audio.c 2007-03-23 17:33:59.000000000 +0100 + +static int snd_usb_caiaq_pcm_trigger(struct snd_pcm_substream *substream, + int cmd) +{ + struct snd_usb_caiaqdev *dev = snd_pcm_substream_chip(substream); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
Put 'case' with the same indent level as switch. (Ditto for all switch blocks in other places.)
Done.
+ switch(buf[0]) { + case EP1_CMD_GET_DEVICE_INFO: + { + memcpy(&dev->spec, buf+1, sizeof(struct caiaq_device_spec));
Don't you need to convert 16bit values for big-endian?
The only value which uses more than one byte of storage is the firmware revision which is unimportant as no runtime decision depends on it. All others are chars and need no endianess care.
Also, some lines are too long. Please try to keep lines in 80 chars as much as possible.
Also done. New patch applied. Daniel
At Mon, 26 Mar 2007 17:46:37 +0200, Daniel Mack wrote:
On Mon, Mar 26, 2007 at 03:45:47PM +0200, Takashi Iwai wrote:
diff -Nur alsa-kernel-ni/usb/caiaq/caiaq-audio.c alsa-kernel/usb/caiaq/caiaq-audio.c --- alsa-kernel-ni/usb/caiaq/caiaq-audio.c 1970-01-01 01:00:00.000000000 +0100 +++ alsa-kernel/usb/caiaq/caiaq-audio.c 2007-03-23 17:33:59.000000000 +0100 + +static int snd_usb_caiaq_pcm_trigger(struct snd_pcm_substream *substream, + int cmd) +{ + struct snd_usb_caiaqdev *dev = snd_pcm_substream_chip(substream); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
Put 'case' with the same indent level as switch. (Ditto for all switch blocks in other places.)
Done.
+ switch(buf[0]) { + case EP1_CMD_GET_DEVICE_INFO: + { + memcpy(&dev->spec, buf+1, sizeof(struct caiaq_device_spec));
Don't you need to convert 16bit values for big-endian?
The only value which uses more than one byte of storage is the firmware revision which is unimportant as no runtime decision depends on it.
Then I'd suggest to fix it up, e.g. dev->spec.fw_version = le16_to_cpu(dev->spec.fw_version); to avoid the future bug.
All others are chars and need no endianess care.
Also, some lines are too long. Please try to keep lines in 80 chars as much as possible.
Also done. New patch applied.
Great. Could you fix the above and resubmit the patch? Then I'll apply it to HG tree. Thanks, Takashi
At Mon, 26 Mar 2007 18:10:03 +0200, Daniel Mack wrote:
On Mon, Mar 26, 2007 at 05:56:02PM +0200, Takashi Iwai wrote:
Also done. New patch applied.
Great. Could you fix the above and resubmit the patch? Then I'll apply it to HG tree.
Applied.
OK, I did some more coding style fixes (remove if ((xxx)) ...), and a trivial fix for struct input_dev. Now it's on HG tree. Please check whether it works for you. Most likely we have to add some fix for building on the older kernels, but I'll do it tomorrow... thanks, Takashi
On 03/26/2007 07:14 PM, Takashi Iwai wrote:
Most likely we have to add some fix for building on the older kernels, but I'll do it tomorrow...
I've been wondering about that. Would it be good to say "version 1.0.15 will be the last version of alsa to support kernels < 2.6"? (1.0.15, or 1.0.16, or ...). Older kernels are likely still used a lot in embedded but do they need other sound hardware then what's already present in alsa currently? If they do, would telling to them to "upgrade already" be unacceptable? 2.6 is over 3 years old... The old driver tree could be maintained in bugfix-mode only then and the new driver tree would just equal the kernel tree. Rene.
At Mon, 26 Mar 2007 19:21:21 +0200, Rene Herman wrote:
On 03/26/2007 07:14 PM, Takashi Iwai wrote:
Most likely we have to add some fix for building on the older kernels, but I'll do it tomorrow...
I've been wondering about that. Would it be good to say "version 1.0.15 will be the last version of alsa to support kernels < 2.6"? (1.0.15, or 1.0.16, or ...). Older kernels are likely still used a lot in embedded but do they need other sound hardware then what's already present in alsa currently? If they do, would telling to them to "upgrade already" be unacceptable? 2.6 is over 3 years old...
In alsa-driver tree, there is a flag (embedded in utils/mod-deps.c) indicating 2.6-only drivers, so it's no big deal. But the problem is that there are too often API changes internally in 2.6 kernels, too. Some are trivial to fix and some are not. Takashi
On 03/26/2007 07:27 PM, Takashi Iwai wrote:
At Mon, 26 Mar 2007 19:21:21 +0200, Rene Herman wrote:
I've been wondering about that. Would it be good to say "version 1.0.15 will be the last version of alsa to support kernels < 2.6"? (1.0.15, or 1.0.16, or ...). Older kernels are likely still used a lot in embedded but do they need other sound hardware then what's already present in alsa currently? If they do, would telling to them to "upgrade already" be unacceptable? 2.6 is over 3 years old...
In alsa-driver tree, there is a flag (embedded in utils/mod-deps.c) indicating 2.6-only drivers, so it's no big deal.
I see. Well, you are the one doing the work so if you don't think it matters, it doesn't :) Rene.
Hi, and thank you for the support of audio 8 dj soundcard. I'd like to know if this driver support all of the 8 inputs/outputs channels, and if someone test it with xwax (xwax.co.uk). Because I'm looking forward to buy this device and I like to play safe. Thank you very much. Kyriakos PS.Sorry for my bad English :)
Hi, On Mar 21, 2008, at 2:07 PM, kyr wrote:
I'd like to know if this driver support all of the 8 inputs/outputs channels, and if someone test it with xwax (xwax.co.uk).
All inputs and outputs are supported, and the developer of xwax wanted to test his software with this interface. However, I don't know about his results or if he ever really did it. Maybe ask on their mailing list? Best regards, Daniel
participants (4)
-
Daniel Mack -
kyr -
Rene Herman -
Takashi Iwai