Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Am Dienstag 06 April 2004 02:10 schrieb Rui Nuno Capela: Now comes the weird part. No, I couldn't get it to work unless I set --with-debug=full on configure line. And I've tested several times, believe me. FYI, I'm stick with 2.6 kernel tree, and already tested with 2.6.4 and latest 2.6.5. My way of building the kernel modules is from stock tarball, and is pretty canonical, as literally as follows (all as root): tar -jxf alsa-driver-1.0.4.tar.bz2 cd alsa-driver-1.0.4 gzip -dc ../alsa-driver-1.0.4p1.patch.gz# see attachment ./configure --with-isapnp=no --with-sequencer=yes --with-oss=yes --with-cards=all --with-debug=full make make install As stated, the INPUT MONITOR LED does not get lit if I take out the clause --with-debug=full. How come? You don't use --with-kernel option. Are you shure ALSA build sees the correct linux-kernel source? What distro are you using? On some (i.e. fc1) you'd have to specify a special gcc like export CC=gcc32 befure ./configure. I'm building a no debug ALSA here with a 2.6.5-aa1 kernel. maybe I'll find something. Cheers, Karsten --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Am Dienstag 06 April 2004 12:52 schrieb Karsten Wiese: Am Dienstag 06 April 2004 02:10 schrieb Rui Nuno Capela: Now comes the weird part. No, I couldn't get it to work unless I set --with-debug=full on configure line. And I've tested several times, believe me. FYI, I'm stick with 2.6 kernel tree, and already tested with 2.6.4 and latest 2.6.5. My way of building the kernel modules is from stock tarball, and is pretty canonical, as literally as follows (all as root): tar -jxf alsa-driver-1.0.4.tar.bz2 cd alsa-driver-1.0.4 gzip -dc ../alsa-driver-1.0.4p1.patch.gz # see attachment ./configure --with-isapnp=no --with-sequencer=yes --with-oss=yes --with-cards=all --with-debug=full make make install As stated, the INPUT MONITOR LED does not get lit if I take out the clause --with-debug=full. How come? You don't use --with-kernel option. Are you shure ALSA build sees the correct linux-kernel source? What distro are you using? On some (i.e. fc1) you'd have to specify a special gcc like export CC=gcc32 befure ./configure. I'm building a no debug ALSA here with a 2.6.5-aa1 kernel. maybe I'll find something. Yes, same odd behavior here: built without --with-debug=full, nothing is sent from us428control to the us428. So your build process is propably ok. Cheers, Karsten --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Karsten Wiese wrote: Now comes the weird part. No, I couldn't get it to work unless I set --with-debug=full on configure line. And I've tested several times, believe me. FYI, I'm stick with 2.6 kernel tree, and already tested with 2.6.4 and latest 2.6.5. My way of building the kernel modules is from stock tarball, and is pretty canonical, as literally as follows (all as root): tar -jxf alsa-driver-1.0.4.tar.bz2 cd alsa-driver-1.0.4 gzip -dc ../alsa-driver-1.0.4p1.patch.gz # see attachment ./configure --with-isapnp=no --with-sequencer=yes --with-oss=yes --with-cards=all --with-debug=full make make install As stated, the INPUT MONITOR LED does not get lit if I take out the clause --with-debug=full. How come? You don't use --with-kernel option. Are you shure ALSA build sees the correct linux-kernel source? My current linux kernel source is always under /usr/src/linux, a pretty standard place. I always build the alsa-driver's under and for the current running kernel. But as I said, the issue is only triggered by whether the --with-debug configure option is there. The build environment remains exactly the same, so I think. What distro are you using? SUSE 9.0 on a desktop, and Mandrake 10.0 on a laptop. The results are, not surprisingly, the same (the build steps are the same too, without --with-kernel option). On some (i.e. fc1) you'd have to specify a special gcc like export CC=gcc32 befure ./configure. Is there any issue with gcc 3.3, which I think is the one I'm using ? I'm building a no debug ALSA here with a 2.6.5-aa1 kernel. maybe I'll find something. Thanks for the patience. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Now comes the weird part. No, I couldn't get it to work unless I set
--with-debug=full on configure line. And I've tested several times,
believe me.
Attached diff fixed it here.
Please verify.
CU
Index: alsa-driver/usb/usx2y/usbusx2y.c
===
RCS file: /cvsroot/alsa/alsa-driver/usb/usx2y/usbusx2y.c,v
retrieving revision 1.8
diff -u -r1.8 usbusx2y.c
--- alsa-driver/usb/usx2y/usbusx2y.c 17 Feb 2004 15:28:31 - 1.8
+++ alsa-driver/usb/usx2y/usbusx2y.c 6 Apr 2004 16:51:22 -
@@ -118,7 +118,6 @@
static void snd_usX2Y_usb_disconnect(struct usb_device* usb_device, void* ptr);
static void snd_usX2Y_card_private_free(snd_card_t *card);
-#ifdef CONFIG_SND_DEBUG
/*
* pipe 4 is used for switching the lamps, setting samplerate, volumes
*/
@@ -128,14 +127,15 @@
void snd_usX2Y_Out04Int(struct urb* urb)
#endif
{
+#ifdef CONFIG_SND_DEBUG
if (urb-status) {
int i;
usX2Ydev_t* usX2Y = urb-context;
for (i = 0; i 10 usX2Y-AS04.urb[i] != urb; i++);
snd_printd(snd_usX2Y_Out04Int() usX2Y-Seq04=%i urb %i status=%i\n, usX2Y-Seq04, i, urb-status);
}
-}
#endif
+}
#ifndef OLD_USB
void snd_usX2Y_In04Int(struct urb* urb, struct pt_regs *regs)
@@ -194,7 +194,7 @@
int j, send = us428ctls-p4outSent + 1;
if (send = N_us428_p4out_BUFS)
send = 0;
-for (j = 0; j URBS_AsyncSeq; ++j)
+for (j = 0; j URBS_AsyncSeq!err; ++j)
if (0 == usX2Y-AS04.urb[j]-status) {
us428_p4out_t *p4out = us428ctls-p4out + send; // FIXME if more then 1 p4out is new, 1 gets lost.
usb_fill_bulk_urb(usX2Y-AS04.urb[j], usX2Y-chip.dev,
@@ -204,7 +204,7 @@
#ifdef OLD_USB
usX2Y-AS04.urb[j]-transfer_flags = USB_QUEUE_BULK;
#endif
- usb_submit_urb(usX2Y-AS04.urb[j], GFP_ATOMIC);
+ err = usb_submit_urb(usX2Y-AS04.urb[j], GFP_ATOMIC);
us428ctls-p4outSent = send;
break;
}
Index: alsa-driver/usb/usx2y/usbusx2y.h
===
RCS file: /cvsroot/alsa/alsa-driver/usb/usx2y/usbusx2y.h,v
retrieving revision 1.3
diff -u -r1.3 usbusx2y.h
--- alsa-driver/usb/usx2y/usbusx2y.h 19 Jan 2004 18:43:28 - 1.3
+++ alsa-driver/usb/usx2y/usbusx2y.h 6 Apr 2004 16:51:22 -
@@ -58,10 +58,6 @@
void snd_usX2Y_In04Int(struct urb* urb);
#endif
-#ifndef CONFIG_SND_DEBUG
-#define snd_usX2Y_Out04Int 0
-#endif
-
#define NAME_ALLCAPS US-X2Y
#endif
Index: alsa-driver/usb/usx2y/usbusx2yaudio.c
===
RCS file: /cvsroot/alsa/alsa-driver/usb/usx2y/usbusx2yaudio.c,v
retrieving revision 1.9
diff -u -r1.9 usbusx2yaudio.c
--- alsa-driver/usb/usx2y/usbusx2yaudio.c 30 Mar 2004 08:27:16 - 1.9
+++ alsa-driver/usb/usx2y/usbusx2yaudio.c 6 Apr 2004 16:51:25 -
@@ -1245,7 +1245,7 @@
snd_dma_continuous_data(GFP_KERNEL),
usX2Y_capt_substream-endpoints * 64*1024,
usX2Y_capt_substream-endpoints * 128*1024)) ||
- (usX2Y(card)-chip.dev-descriptor.idProduct == USB_ID_US428
+ (usX2Y(card)-chip.dev-descriptor.idProduct != USB_ID_US122
0 (err = usX2Y_rate_set(usX2Y_stream, 44100 { // Lets us428 recognize output-volume settings, disturbs us122.
snd_usX2Y_audio_stream_free(usX2Y_stream);
return err;
Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Karsten Wiese Now comes the weird part. No, I couldn't get it to work unless I set --with-debug=full on configure line. And I've tested several times, believe me. Attached diff fixed it here. Please verify. CU First try and it works, that is without debug enabled. Thankful. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Am Samstag 03 April 2004 03:24 schrieb Rui Nuno Capela:
I have news, and they're good this time.
After some juggling and persistance around compiling and patching the
snd-usb-usx2y module, I've finally got that dreaded INPUT MONITOR LED come
to light and, as Karsten rightly predicted, playback has shown its ugly
head on my Tascam US-224. Hip, hip, hurray!
Like a miracle, the MUTE and SELECT LED lights of the mixer strips 1-4 are
lightning up too. Again, Karsten tips are quite cirurgical :)
However, I don't get the SOLO, REC, NULL, nor all other transport LEDs to
lit. But that's yet another step, I think the next.
Ok, go for it. Should be fairly easy. Just implement the sink-side of the
alsa-sequencer interface in us428control ;-)
erm no it is not implemented yet.
The Transport Lights could react to MMC Messages.
MUTE, REC, SOLO SELECT Lights would be controlled by i. e. ardour.
NULL-Mode is a little more complicated:
In INPUT MONITOR Mode us428control knows all to handle it.
In not INPUT MONITOR Mode us428control has to know from i. e. Ardour the Mixer
Settings to compare them with the actual state.
We're getting near and I'm quite happier now.
Karsten Wiese wrote:
So please try the following patch:
--- alsa-driver/usb/usx2y/usbusx2yaudio.c 30 Mar 2004 08:27:16 - 1.9
+++ alsa-driver/usb/usx2y/usbusx2yaudio.c 2 Apr 2004 11:55:21 -
@@ -1245,7 +1245,7 @@
snd_dma_continuous_data(GFP_KERNEL),
usX2Y_capt_substream-endpoints *
64*1024,
usX2Y_capt_substream-endpoints *
128*1024)) ||
- (usX2Y(card)-chip.dev-descriptor.idProduct == USB_ID_US428
+ (usX2Y(card)-chip.dev-descriptor.idProduct != USB_ID_US122
0 (err = usX2Y_rate_set(usX2Y_stream, 44100 {// Lets us428
recognize output-volume settings, disturbs us122.
snd_usX2Y_audio_stream_free(usX2Y_stream);
return err;
if the us428 doesn't get the usX2Y_rate_set(usX2Y_stream, 44100) at
startup, it later behaves ignorant to light volume setting. like
us224 behaves now.
That was it. Although I only got it working after one last
alsa-driver-1.0.3 rebuild and when set --with-debug=full on ./configure.
Kind of strange. My literal patch applied to stock alsa-driver-1.0.3 is on
attachment. It is just the same of Karsten's supplied above, just for
reference.
Please make shure it also works without debug mode. after make clean.
If we get the INPUT MONITOR Led enlightened, the Volume settings should
also work with respect to direct monitoring at least. US224 Master Fader
seams to b where US428's Fader5 is. That needs adjustment in
s428control.
The data sent to set us224 internal mixers is filtered out with
grep -n 00: 0[0123456789] .. .. .. ..$ USB224_usbsnoop1.log
it gives i. e.:
11721:: 00 00 25 00 25
11732:: 01 00 25 00 25
11743:: 02 00 25 00 25
11754:: 03 00 25 00 25
11831:: 04 00 42 00 42
look at struct usX2Y_volume and its methods. it should fit the us224.
But lets get that Leds enlighted first :-)
The master fader works, at least while on playback. I don't seem to get
fader strips 1-4 to have any audible effect. But now's too early to judge
my experiments.
Is Direct Monitoring not working? Please try. Has the us224 got SPDIF besides
the 2 Anolog Ins?
I'm wondering why there are 5 internal mixers being set.
4 should be PCM from usb,
0 shold be Chanell A Monitor and
1 shold be Chanell B Monitor
What are 2 and 3?
CU
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Tascam US-224 progress report (was: USB224_usbsnoop1.log captured on WinXP)
Karsten Wiese wrote: Am Samstag 03 April 2004 03:24 schrieb Rui Nuno Capela: I have news, and they're good this time. After some juggling and persistance around compiling and patching the snd-usb-usx2y module, I've finally got that dreaded INPUT MONITOR LED come to light and, as Karsten rightly prehome/rncbc/dicted, playback has shown its ugly head on my Tascam US-224. Hip, hip, hurray! Like a miracle, the MUTE and SELECT LED lights of the mixer strips 1-4 are lightning up too. Again, Karsten tips are quite cirurgical :) However, I don't get the SOLO, REC, NULL, nor all other transport LEDs to lit. But that's yet another step, I think the next. Ok, go for it. Should be fairly easy. Just implement the sink-side of the alsa-sequencer interface in us428control ;-) erm no it is not implemented yet. The Transport Lights could react to MMC Messages. MUTE, REC, SOLO SELECT Lights would be controlled by i. e. ardour. Oh yeah? That's great, but I'm afraid my ardour is still with it's default configuration (trident anyone?). Does anybody have a quick and dirty solution on how to change this? Please forgive my idleness :) NULL-Mode is a little more complicated: In INPUT MONITOR Mode us428control knows all to handle it. In not INPUT MONITOR Mode us428control has to know from i. e. Ardour the Mixer Settings to compare them with the actual state. I don't even have a clear idea on whether this NULL-mode is all about, so let's leave it for a little bit later, OK? :) Please make shure it also works without debug mode. after make clean. Now comes the weird part. No, I couldn't get it to work unless I set --with-debug=full on configure line. And I've tested several times, believe me. FYI, I'm stick with 2.6 kernel tree, and already tested with 2.6.4 and latest 2.6.5. My way of building the kernel modules is from stock tarball, and is pretty canonical, as literally as follows (all as root): tar -jxf alsa-driver-1.0.4.tar.bz2 cd alsa-driver-1.0.4 gzip -dc ../alsa-driver-1.0.4p1.patch.gz # see attachment ./configure --with-isapnp=no --with-sequencer=yes --with-oss=yes --with-cards=all --with-debug=full make make install As stated, the INPUT MONITOR LED does not get lit if I take out the clause --with-debug=full. How come? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] alsa-driver-1.0.4p1.patch.gz Description: GNU Zip compressed data
