Re: [Alsa-devel] aserver, smix
On Sat, 1 Mar 2003, Patrick Shirkey wrote: > Jaroslav Kysela wrote: > > > Note that we have actually the experimental dmix plugin (direct mixing) > > which works for i386 architecture in CVS. The usage is simple: > > > > aplay -Dplug:dmix > > > > You may pass 'plug:dmix' to any other application. > > > > When I try this I get this error: > > ~$ aplay -D plug:dmix -f cd track_8.wav > ALSA lib pcm_hw.c:371:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS > failed: Invalid argument > ALSA lib pcm_dmix.c:1378:(snd_pcm_dmix_initialize_slave) unable to > install sw params > ALSA lib pcm_dmix.c:1534:(snd_pcm_dmix_open) unable to initialize slave > > aplay: main:479: audio open error: Invalid argument > > Using the example for the .asoundrc file in the original dmix thread is > the same. > > ~$ aplay -D dmix -f cd track_8.wav > ALSA lib pcm_hw.c:371:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS > failed: Invalid argument > ALSA lib pcm_dmix.c:1378:(snd_pcm_dmix_initialize_slave) unable to > install sw params > ALSA lib pcm_dmix.c:1534:(snd_pcm_dmix_open) unable to initialize slave > > aplay: main:479: audio open error: Invalid argument Are you using latest CVS drivers? Previous drivers are not compatible. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Interesting problem with hotplug and Midisport 2x2on Mdk 9.0
Patrick Shirkey wrote: Takashi Iwai wrote: I see it too with the quattro and another user has reported it with the audigy. It would be nicer if we didn't have to remember to unload the usb-audio driver before hotplugging. Is it possible to make that happen. then there is still a bug in this regard. are you using MIDI on quattro, too? It is automatically used. Clemens would have to explain as I cannot remember the exact details. I another bug I was just reminded of is that if I remove the alsa modules while the usb device is still switched on I get a complete hang where I have to restart with alt+sysreq+b -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] aserver, smix
Jaroslav Kysela wrote: Note that we have actually the experimental dmix plugin (direct mixing) which works for i386 architecture in CVS. The usage is simple: aplay -Dplug:dmix You may pass 'plug:dmix' to any other application. When I try this I get this error: ~$ aplay -D plug:dmix -f cd track_8.wav ALSA lib pcm_hw.c:371:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ALSA lib pcm_dmix.c:1378:(snd_pcm_dmix_initialize_slave) unable to install sw params ALSA lib pcm_dmix.c:1534:(snd_pcm_dmix_open) unable to initialize slave aplay: main:479: audio open error: Invalid argument Using the example for the .asoundrc file in the original dmix thread is the same. ~$ aplay -D dmix -f cd track_8.wav ALSA lib pcm_hw.c:371:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ALSA lib pcm_dmix.c:1378:(snd_pcm_dmix_initialize_slave) unable to install sw params ALSA lib pcm_dmix.c:1534:(snd_pcm_dmix_open) unable to initialize slave aplay: main:479: audio open error: Invalid argument -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Interesting problem with hotplug and Midisport 2x2on Mdk 9.0
Takashi Iwai wrote: I see it too with the quattro and another user has reported it with the audigy. It would be nicer if we didn't have to remember to unload the usb-audio driver before hotplugging. Is it possible to make that happen. then there is still a bug in this regard. are you using MIDI on quattro, too? It is automatically used. Clemens would have to explain as I cannot remember the exact details. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] Edirol UA-20 PCM support
Hallo, Clemens Ladisch hat gesagt: // Clemens Ladisch wrote: > The new parsing code works with my device (UA-1A), but I couldn't test the > changes for the mixer and the UA-20. I'm sorry, that I cannot test this anymore on the UA-20 that was mine until today, 11:00 :( when I sent it back. But I'd still like to thank you Clemens, for the work you did on that driver. I hope, the next buyer can use the UA-20 which in general seemed to be a nice interface - but it's just 2-channel... ciao -- Frank Barknecht _ __footils.org__ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] via82xx: alsa-docs note
At Thu, 27 Feb 2003 03:01:46 +0900, Patrick Shirkey wrote: > > I'm wondering if this is a bug that can be fixed or not. > > The following has been submitted as a note for the documentation of via82xx. > > sender: [EMAIL PROTECTED] > date: Saturday, 18 January 2003 > > > I don't use sonypi with via82xx on my VAIO Laptop > because sonypi and via82xx try to use the same region > and I obtained this error message : > > unable to grab ports 0x1000-0x10ff hmm, it's over what the sound driver can do, if it really overlapps the region. a better quirk for the pci would be needed... Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] new DMA buffer management
Hi, i changed the management of (PCM) DMA buffers on the cvs version. now there is a new module, snd-page-alloc, which includes the generic memory allocators for various (bus) types. this module is independent from snd module, so that it can keep the allocated buffers after snd-* modules are un/reloaded. i.e. it works like snd-hammerfall-mem does, but in more generic way. this feature is useful for cards like ice1712 which need a big continuous physical area. the new alsasound init script keeps this module after stop operation. so, if you find this module after alsasound stop, don't be surprised. the changes have been done in the middle-layer, and they don't appear much on the top or low-level code. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp driver
Hi Paul, At Thu, 27 Feb 2003 13:43:34 -0500, Paul Davis wrote: > > i haven't had time today to get the patch for the hdsp ready. however, > the new source works here (i have some CVS sync issues). i'll get it > out to the list on monday (i'm gone for the weekend). could you check the attached patch (to the current cvs version) for rme9652 and hdsp? it will replace the memory allocation using the new snd-page-alloc module instead of snd-hammerfall-mem. although the former doesn't allocate the buffer in advance by checking the pci id, but it will preserve the buffers at alsasound stop or restart operations just like the latter does. Takashi rme-mem-new.dif Description: Binary data
Re: [Alsa-devel] [PATCH] midi_voices
At Fri, 28 Feb 2003 12:57:21 +0100 (MET), Clemens Ladisch wrote: > > > Isn't it really nice that there are ioctls and library functions to get/ > set the midi_voices property of sequencer ports? > > Well, it would be, if ports actually had this property. :o) egg or chicken? :) thanks, now on cvs. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] Edirol UA-20 PCM support
At Fri, 28 Feb 2003 12:33:02 +0100 (MET), Clemens Ladisch wrote: > > Takashi Iwai wrote: > > could you resend the patch if finished? > > The new parsing code works with my device (UA-1A), but I couldn't test the > changes for the mixer and the UA-20. > > > - removed buffer allocation for class-specific descriptors; get them from > intf->extra and ep->extra. that's nice. > - accept USB_CLASS_VENDOR_SPECIFIC when parsing audio interfaces > - added quirk type for interfaces having standard descriptors > - added quirk for UA-20 thanks, applied to cvs. seems working fine with my usb-speaker. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [lack of] dynamic detection/loading of modules
At 27 Feb 2003 12:35:00 -0800, Fernando Pablo Lopez-Lezcano wrote: > > > >lists about this and to do it cleanly it would be nice to have available > > >in /proc/asound the list of modules currently loaded. That is not > > >available today (I think Takashi said he might add that)." > > > > cat /proc/modules | grep '^snd' > > This relies in an (AFAIK) unenforceable convention (all modules that > start with "snd" are alsa modules). I think the information has to come > from within the alsa driver, or from some place that actually knows that > the module _is_ an alsa module. IMHO a name is not enough. ok, i added the code. the cvs version shows the list of modules on /proc/asound/modules. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] HDSP 9652 MIDI IN - stuck notes
On Fri, 2003-02-28 at 04:56, Mark Knecht wrote: > > at least, we need to check whether the interrupts for MIDI are > > generated properly. > > please try the following. > > > > 1. connect HDSP MIDI1 input to HDSP MIDI1 output via aconnect. > > 2. trigger a note from MIDI1 input. > >check whether the IRQ count in /proc/interrupts (for HDSP) > >increases. > >during this test, don't use HDSP audio. > > > > [EMAIL PROTECTED] card1]$ more /proc/interrupts >CPU0 > 0: 62488 XT-PIC timer > 1:816 XT-PIC keyboard > 2: 0 XT-PIC cascade > 5:749 XT-PIC usb-uhci, usb-uhci, usb-uhci, eth0 > 8: 1 XT-PIC rtc > 10: 94 XT-PIC hdsp > 11: 5 XT-PIC ohci1394 > 12: 7033 XT-PIC PS/2 Mouse > 14: 8556 XT-PIC ide2 > 15: 9005 XT-PIC ide3 > NMI: 0 > ERR: 0 > [EMAIL PROTECTED] card1]$ BTW - The HDSP interrupts above do not represent a failure. All I did is what you asked me to do. If you asked me to wait for a failure, we'd have 1000's on interrupts at least, I'm sure, and I don't know how we would identify that one did not happen. Also, if I wasn't clear earlier, the failure is ONE stuck note. The MIDI input keeps working, and subsequent notes work properly. (both on and off) It's just that a single note gets stuck every 1-2 minutes. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [patch] set_power_state bug
On Fri, 28 Feb 2003, Arnaud de Bossoreille de Ribou wrote: > Hello, > > there's a bug introduced in the 1.25 revision of the file > "alsa-kernel/core/control.c" which is fixed with the attached patch. I've applied a better fix to CVS. Thanks for your notice. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] HDSP 9652 MIDI IN - stuck notes
On Fri, 2003-02-28 at 04:14, Takashi Iwai wrote: > At 26 Feb 2003 20:47:41 -0800, > Mark Knecht wrote: > > > >If I then change my keyboard to drive the HDSP 9652 input 1 (Alsa > > 64:0) and change the connections internally to drive all of outputs, I > > get stuck notes pretty much immediately. It seems a bit worse with the > > sustain pedal, but does not seem to be effected at all by controllers. > > It is heavily effected by the MIDI note density. If I hit only one or > > two notes, I'm not likely to get it, but using the sustain pedal I can > > create the problem in under a minute. > > > >To be sure it's the input and not the outputs (as much as I can be) I > > have external synths attached to the Alsa outputs on 64:0, 72:0 and > > 72:1. When I get a stuck note, I seem to get it on both internal soft > > synths and all three external hardware synths at the same time. For this > > reason I deduce that it is the HDSP input that is not clearing out > > whatever event queue that holds this stuff and somehow the note never > > shuts off. > > to be sure, the configuration which doesn't work is like below, ok? > > HDSP MIDI1 input -> softsynth > > and/or > > HDSP MIDI1 input -> HDSP MIDI1 output -> external device Both don't work, and when they fail, they both fail at the same time in the same way, with a note stuck on. That's why I titled the thread HDSP MIDI In - stuck notes. (I'm actually using MIDI 0, not MIDI 1) -> softsynth | HDSP MIDI 0 -- | -> HDSP MIDI 0 output -> external synth Using the USB MIDI in does not fail: -> softsynth | MidiSport 0 -- | -> HDSP MIDI 0 output -> external synth > > at least, we need to check whether the interrupts for MIDI are > generated properly. > please try the following. > > 1. connect HDSP MIDI1 input to HDSP MIDI1 output via aconnect. > 2. trigger a note from MIDI1 input. >check whether the IRQ count in /proc/interrupts (for HDSP) >increases. >during this test, don't use HDSP audio. > [EMAIL PROTECTED] card1]$ more /proc/interrupts CPU0 0: 62488 XT-PIC timer 1:816 XT-PIC keyboard 2: 0 XT-PIC cascade 5:749 XT-PIC usb-uhci, usb-uhci, usb-uhci, eth0 8: 1 XT-PIC rtc 10: 94 XT-PIC hdsp 11: 5 XT-PIC ohci1394 12: 7033 XT-PIC PS/2 Mouse 14: 8556 XT-PIC ide2 15: 9005 XT-PIC ide3 NMI: 0 ERR: 0 [EMAIL PROTECTED] card1]$ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [patch] set_power_state bug
Hello,
there's a bug introduced in the 1.25 revision of the file
"alsa-kernel/core/control.c" which is fixed with the attached patch.
Please apply :-)
Bye,
--
Arnaud
--- alsa-kernel/core/control.c 2003-01-13 10:49:43.0 +0100
+++ alsa-kernel/core/control.c 2003-02-28 13:27:58.0 +0100
@@ -714,15 +714,16 @@
return -EFAULT;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- err = -ENOPROTOOPT;
#ifdef CONFIG_PM
if (card->set_power_state) {
snd_power_lock(card);
err = card->set_power_state(card, err);
snd_power_unlock(card);
}
-#endif
return err;
+#else
+ return -ENOPROTOOPT;
+#endif
case SNDRV_CTL_IOCTL_POWER_STATE:
#ifdef CONFIG_PM
return put_user(card->power_state, (int *)arg) ? -EFAULT : 0;
Re: [Alsa-devel] HDSP 9652 MIDI IN - stuck notes
At 26 Feb 2003 20:47:41 -0800, Mark Knecht wrote: > >If I then change my keyboard to drive the HDSP 9652 input 1 (Alsa > 64:0) and change the connections internally to drive all of outputs, I > get stuck notes pretty much immediately. It seems a bit worse with the > sustain pedal, but does not seem to be effected at all by controllers. > It is heavily effected by the MIDI note density. If I hit only one or > two notes, I'm not likely to get it, but using the sustain pedal I can > create the problem in under a minute. > >To be sure it's the input and not the outputs (as much as I can be) I > have external synths attached to the Alsa outputs on 64:0, 72:0 and > 72:1. When I get a stuck note, I seem to get it on both internal soft > synths and all three external hardware synths at the same time. For this > reason I deduce that it is the HDSP input that is not clearing out > whatever event queue that holds this stuff and somehow the note never > shuts off. to be sure, the configuration which doesn't work is like below, ok? HDSP MIDI1 input -> softsynth and/or HDSP MIDI1 input -> HDSP MIDI1 output -> external device at least, we need to check whether the interrupts for MIDI are generated properly. please try the following. 1. connect HDSP MIDI1 input to HDSP MIDI1 output via aconnect. 2. trigger a note from MIDI1 input. check whether the IRQ count in /proc/interrupts (for HDSP) increases. during this test, don't use HDSP audio. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Interesting problem with hotplug and Midisport 2x2 on Mdk 9.0
At Fri, 28 Feb 2003 14:51:08 +0900, Patrick Shirkey wrote: > > Takashi Iwai wrote: > > > > > hmm, the hot unplugging of ALSA usb devices was improved in the recent > > version - basically i didn't see problems with the devices i have. > > but i've not tested with midi devices, so this might be a problem. > > > > just make sure that you unload snd-usb-audio (snd-usb-midi doesn't > > exist any longer) before unplugging the device. > > > > > > > I see it too with the quattro and another user has reported it with the > audigy. It would be nicer if we didn't have to remember to unload the > usb-audio driver before hotplugging. Is it possible to make that happen. then there is still a bug in this regard. are you using MIDI on quattro, too? Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] Edirol UA-20 PCM support
Takashi Iwai wrote:
> could you resend the patch if finished?
The new parsing code works with my device (UA-1A), but I couldn't test the
changes for the mixer and the UA-20.
- removed buffer allocation for class-specific descriptors; get them from
intf->extra and ep->extra.
- accept USB_CLASS_VENDOR_SPECIFIC when parsing audio interfaces
- added quirk type for interfaces having standard descriptors
- added quirk for UA-20
Index: alsa-kernel/usb/usbaudio.c
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.45
diff -u -r1.45 usbaudio.c
--- alsa-kernel/usb/usbaudio.c 25 Feb 2003 12:35:45 - 1.45
+++ alsa-kernel/usb/usbaudio.c 28 Feb 2003 10:34:19 -
@@ -1556,15 +1556,11 @@
/*
* parse descriptor buffer and return the pointer starting the given
- * descriptor type and interface.
- * if altsetting is not -1, seek the buffer until the matching alternate
- * setting is found.
+ * descriptor type.
*/
-void *snd_usb_find_desc(void *descstart, int desclen, void *after,
- u8 dtype, int iface, int altsetting)
+void *snd_usb_find_desc(void *descstart, int desclen, void *after, u8 dtype)
{
u8 *p, *end, *next;
- int ifc = -1, as = -1;
p = descstart;
end = p + desclen;
@@ -1574,15 +1570,7 @@
next = p + p[0];
if (next > end)
return NULL;
- if (p[1] == USB_DT_INTERFACE) {
- /* minimum length of interface descriptor */
- if (p[0] < 9)
- return NULL;
- ifc = p[2];
- as = p[3];
- }
- if (p[1] == dtype && (!after || (void *)p > after) &&
- (iface == -1 || iface == ifc) && (altsetting == -1 || altsetting
== as)) {
+ if (p[1] == dtype && (!after || (void *)p > after)) {
return p;
}
p = next;
@@ -1593,12 +1581,12 @@
/*
* find a class-specified interface descriptor with the given subtype.
*/
-void *snd_usb_find_csint_desc(void *buffer, int buflen, void *after, u8 dsubtype, int
iface, int altsetting)
+void *snd_usb_find_csint_desc(void *buffer, int buflen, void *after, u8 dsubtype)
{
unsigned char *p = after;
while ((p = snd_usb_find_desc(buffer, buflen, p,
- USB_DT_CS_INTERFACE, iface, altsetting)) !=
NULL) {
+ USB_DT_CS_INTERFACE)) != NULL) {
if (p[0] >= 3 && p[2] == dsubtype)
return p;
}
@@ -1950,7 +1938,7 @@
}
-static int parse_audio_endpoints(snd_usb_audio_t *chip, unsigned char *buffer, int
buflen, int iface_no)
+static int parse_audio_endpoints(snd_usb_audio_t *chip, int iface_no)
{
struct usb_device *dev;
struct usb_host_config *config;
@@ -1971,7 +1959,8 @@
alts = &iface->altsetting[i];
altsd = get_iface_desc(alts);
/* skip invalid one */
- if (altsd->bInterfaceClass != USB_CLASS_AUDIO ||
+ if ((altsd->bInterfaceClass != USB_CLASS_AUDIO &&
+altsd->bInterfaceClass != USB_CLASS_VENDOR_SPEC) ||
altsd->bInterfaceSubClass != USB_SUBCLASS_AUDIO_STREAMING ||
altsd->bNumEndpoints < 1)
continue;
@@ -1985,7 +1974,7 @@
altno = altsd->bAlternateSetting;
/* get audio formats */
- fmt = snd_usb_find_csint_desc(buffer, buflen, NULL, AS_GENERAL,
iface_no, altno);
+ fmt = snd_usb_find_csint_desc(alts->extra, alts->extralen, NULL,
AS_GENERAL);
if (!fmt) {
snd_printk(KERN_ERR "%d:%u:%d : AS_GENERAL descriptor not
found\n",
dev->devnum, iface_no, altno);
@@ -2001,7 +1990,7 @@
format = (fmt[6] << 8) | fmt[5]; /* remember the format value */
/* get format type */
- fmt = snd_usb_find_csint_desc(buffer, buflen, NULL, FORMAT_TYPE,
iface_no, altno);
+ fmt = snd_usb_find_csint_desc(alts->extra, alts->extralen, NULL,
FORMAT_TYPE);
if (!fmt) {
snd_printk(KERN_ERR "%d:%u:%d : no FORMAT_TYPE desc\n",
dev->devnum, iface_no, altno);
@@ -2031,7 +2020,7 @@
continue;
}
- csep = snd_usb_find_desc(buffer, buflen, NULL, USB_DT_CS_ENDPOINT,
iface_no, altno);
+ csep = snd_usb_find_desc(alts->endpoint[0].extra,
alts->endpoint[0].extralen, NULL, USB_DT_CS_ENDPOINT);
if (!csep || csep[0] < 7 || csep[2] != EP_GENERAL) {
snd_printk(KERN_ERR "%d:%u:%d : no or invalid class specific
endpoint descriptor
[Alsa-devel] [PATCH] midi_voices
Isn't it really nice that there are ioctls and library functions to get/
set the midi_voices property of sequencer ports?
Well, it would be, if ports actually had this property. :o)
Index: alsa-kernel/core/seq/seq_ports.h
===
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_ports.h,v
retrieving revision 1.2
diff -u -r1.2 seq_ports.h
--- alsa-kernel/core/seq/seq_ports.h30 Dec 2001 09:26:45 - 1.2
+++ alsa-kernel/core/seq/seq_ports.h28 Feb 2003 10:35:06 -
@@ -81,6 +81,7 @@
/* supported channels */
int midi_channels;
+ int midi_voices;
int synth_voices;
} client_port_t;
Index: alsa-kernel/core/seq/seq_ports.c
===
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_ports.c,v
retrieving revision 1.12
diff -u -r1.12 seq_ports.c
--- alsa-kernel/core/seq/seq_ports.c5 Feb 2003 11:07:51 - 1.12
+++ alsa-kernel/core/seq/seq_ports.c28 Feb 2003 10:35:06 -
@@ -351,6 +351,7 @@
/* information about supported channels/voices */
port->midi_channels = info->midi_channels;
+ port->midi_voices = info->midi_voices;
port->synth_voices = info->synth_voices;
return 0;
@@ -372,6 +373,7 @@
/* information about supported channels/voices */
info->midi_channels = port->midi_channels;
+ info->midi_voices = port->midi_voices;
info->synth_voices = port->synth_voices;
/* get subscriber counts */
@@ -611,7 +613,7 @@
int snd_seq_event_port_attach(int client,
snd_seq_port_callback_t *pcbp,
int cap, int type, int midi_channels,
- char *portname)
+ int midi_voices, char *portname)
{
snd_seq_port_info_t portinfo;
int ret;
@@ -628,6 +630,7 @@
portinfo.type = type;
portinfo.kernel = pcbp;
portinfo.midi_channels = midi_channels;
+ portinfo.midi_voices = midi_voices;
/* Create it */
ret = snd_seq_kernel_client_ctl(client,
Index: alsa-kernel/include/seq_kernel.h
===
RCS file: /cvsroot/alsa/alsa-kernel/include/seq_kernel.h,v
retrieving revision 1.6
diff -u -r1.6 seq_kernel.h
--- alsa-kernel/include/seq_kernel.h5 Feb 2003 11:07:52 - 1.6
+++ alsa-kernel/include/seq_kernel.h28 Feb 2003 10:35:06 -
@@ -174,7 +174,7 @@
/* port attach/detach */
int snd_seq_event_port_attach(int client, snd_seq_port_callback_t *pcbp,
- int cap, int type, int midi_channels, char *portname);
+ int cap, int type, int midi_channels, int midi_voices,
char *portname);
int snd_seq_event_port_detach(int client, int port);
#endif /* __SOUND_SEQ_KERNEL_H */
Index: alsa-kernel/drivers/opl3/opl3_oss.c
===
RCS file: /cvsroot/alsa/alsa-kernel/drivers/opl3/opl3_oss.c,v
retrieving revision 1.9
diff -u -r1.9 opl3_oss.c
--- alsa-kernel/drivers/opl3/opl3_oss.c 5 Feb 2003 11:07:52 - 1.9
+++ alsa-kernel/drivers/opl3/opl3_oss.c 28 Feb 2003 10:35:06 -
@@ -101,7 +101,7 @@
SNDRV_SEQ_PORT_TYPE_MIDI_GENERIC |
SNDRV_SEQ_PORT_TYPE_MIDI_GM |
SNDRV_SEQ_PORT_TYPE_SYNTH,
- voices,
+ voices, voices,
name);
if (opl3->oss_chset->port < 0) {
snd_midi_channel_free_set(opl3->oss_chset);
Index: alsa-kernel/drivers/opl3/opl3_seq.c
===
RCS file: /cvsroot/alsa/alsa-kernel/drivers/opl3/opl3_seq.c,v
retrieving revision 1.10
diff -u -r1.10 opl3_seq.c
--- alsa-kernel/drivers/opl3/opl3_seq.c 5 Feb 2003 11:07:52 - 1.10
+++ alsa-kernel/drivers/opl3/opl3_seq.c 28 Feb 2003 10:35:06 -
@@ -179,8 +179,10 @@
{
snd_seq_port_callback_t callbacks;
char name[32];
- int opl_ver;
+ int voices, opl_ver;
+ voices = (opl3->hardware < OPL3_HW_OPL3) ?
+ MAX_OPL2_VOICES : MAX_OPL3_VOICES;
opl3->chset = snd_midi_channel_alloc_set(16);
if (opl3->chset == NULL)
return -ENOMEM;
@@ -204,7 +206,7 @@
SNDRV_SEQ_PORT_TYPE_MIDI_GENERIC
|
SNDRV_SEQ_PORT_TYPE_MIDI_GM |
SNDRV_SEQ_PORT_TYPE_SYNTH,
- 16,
+
RE: [Alsa-devel] AC3 passthru intel8x0 + cs4299
Hi, here are my current config lspci -v 00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02) Subsystem: Siemens Nixdorf AG: Unknown device 0051 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 2000 [size=256] I/O ports at 1800 [size=64] - 0-0/0: Cirrus Logic CS4299 rev 4 Capabilities : -headphone out- DAC resolution : 20-bit ADC resolution : 18-bit 3D enhancement : Crystal Semi 3D Stereo Enhancement Current setup Mic gain : +20dB [+20dB] POP path : pre 3D Sim. stereo : off 3D enhancement : on Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Extended ID : codec=0 rev=0 AMAP DSA=0 VRA Extended status : VRA PCM front DAC: 48000Hz PCM ADC : 48000Hz SPDIF Control: Consumer PCM Copyright Category=0x2 Generation=1 Rate=48kHz E nabled - 0:00 = 1990 0:02 = 1313 0:04 = 1f1f 0:06 = 001f 0:08 = 0:0a = 001e 0:0c = 001f 0:0e = 005f 0:10 = 1f1f 0:12 = 1f1f 0:14 = 1f1f 0:16 = 1f1f 0:18 = 1f1f 0:1a = 0:1c = 0:1e = 0:20 = 2000 0:22 = 0:24 = 0:26 = 000f 0:28 = 0201 0:2a = 0001 0:2c = bb80 0:2e = 0:30 = 0:32 = bb80 0:34 = 0:36 = 0:38 = 0:3a = 0:3c = 0:3e = 0:40 = 0:42 = 0:44 = 0:46 = 0:48 = 0:4a = 0:4c = 0:4e = 0:50 = 0:52 = 0:54 = 0:56 = 0:58 = 0:5a = 0404 0:5c = 0:5e = 0080 0:60 = 0022 0:62 = 0:64 = 0:66 = 0:68 = 8824 0:6a = 0:6c = 0:6e = 0:70 = 0:72 = 0:74 = 0:76 = 0:78 = 007e 0:7a = 0:7c = 4352 0:7e = 5934 - Intel8x0 Global control: 0x0002 Global status : 0x0100 AC'97 codecs ready: primary - 0 [82801AAICH ]: ICH - Intel 82801AA-ICH Intel 82801AA-ICH at 0x2000, irq 5 -- 0: [0- 0]: ctl 16: [0- 0]: digital audio playback 24: [0- 0]: digital audio capture 33: : timer --- pcm 00-00: Intel ICH : Intel 82801AA-ICH : playback 1 : capture 1 --- what I'm trying , change no audio bit to 1 reg 0x68 in ac97_codec.c snd_ac97_spdif_default_put(). but I get errors in intel8x0: clocking to 48000 ALSA ../alsa-kernel/pci/intel8x0.c:521: codec_semaphore: semaphore is not ready[0x1][0x100] ALSA ../alsa-kernel/pci/intel8x0.c:553: codec_read 0: semaphore is not ready for register 0x56 I try activate the SPSA control in snd_ac97_mixer_build() like cs4205. I also have no clue right now about the registers 0x30 and 0x34. 0x34 is maybe Codec Write Semaphore Register CU Bernd Zierath --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [PATCH] reduce large oss_pcm stack usage
On Thu, 27 Feb 2003, Randy.Dunlap wrote: > Hi, > > Jaroslav, Please review and apply. > Patch applies to 2.5.63. > Builds cleanly. Applied. Thanks. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
