[PATCH] USB MIDI driver

[PATCH] USB MIDI driver

[Clemens Ladisch]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]


Attached is a patch for a USB MIDI driver.
Essentially, it does the same as my USB MIDI daemon.

The source is put into the alsa-kernel tree, not into alsa-driver like
the usb-audio driver.

I don't know whether my changes to scripts/Modules.dep make any sense,
please review them before applying.


Clemens

[-- Attachment #2: usbmidi-patch.gz --]
[-- Type: application/octet-stream, Size: 11614 bytes --]

Re: [PATCH] USB MIDI driver

[Takashi Iwai]

Hi,

At Mon, 01 Jul 2002 19:07:40 +0200,
Clemens Ladisch wrote:
> 
> Attached is a patch for a USB MIDI driver.
> Essentially, it does the same as my USB MIDI daemon.
> 
> The source is put into the alsa-kernel tree, not into alsa-driver like
> the usb-audio driver.

i prefer putting it onto alsa-driver at first unless it's confirmed as
enough stable after tarball release.  alsa-kernel is the tree to be
merged into 2.5 kernel.  also, the location of usb drivers is still a
question, whether on sound tree or on drivers/usb tree.

anyway, i'll check the code into cvs after review (if there is no
objection).


thanks,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

USB recording - repetitive peaks

[Patrick Shirkey]

Thanks to your patch Takashi we have two people who have been able to 
record through the quattro.

We have both found that there is a constant repetitive peak in the 
signal which reminds me of the problems I had with the cmipci for a 
brief period.

Thorsten Hass has recorded a perfect example for you which he did using 
aplay and arecord. It is a sine wave so is easy on the ears.

http://www.thorstenhaas.de/alsa/audio.file

He has also generated a jpeg plotted by an oscilloscope while recording 
which I can send you if it will help.

He has also asked if there is any chance you will have time to look at 
this in the two weeks. I believe he has to do some work with his device 
so needs to make a decision about which OS to use for the job.



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Takashi Iwai]

At Tue, 02 Jul 2002 12:36:55 +0200,
I wrote:
> 
> At Mon, 01 Jul 2002 19:07:40 +0200,
> Clemens Ladisch wrote:
> > 
> > Attached is a patch for a USB MIDI driver.
> > Essentially, it does the same as my USB MIDI daemon.
> > 
> > The source is put into the alsa-kernel tree, not into alsa-driver like
> > the usb-audio driver.
> 
> i prefer putting it onto alsa-driver at first unless it's confirmed as
> enough stable after tarball release.  alsa-kernel is the tree to be
> merged into 2.5 kernel.  also, the location of usb drivers is still a
> question, whether on sound tree or on drivers/usb tree.
> 
> anyway, i'll check the code into cvs after review (if there is no
> objection).

ok, now it's there.  as written above, i put it to alsa-driver tree.
let us move the usb stuff later to the official kernel place.

your codes have been slightly modified:

- usb compatibility hack was moved to wrapper.h, so that it can be
  shared with usbuadio.c

- newly added virmidi registrations.
  that means, snd-usb-midi will have its own rawmidi devices
  automatically as /dev/snd/midiCxDx.
  this will be good for applications which speak only with
  rawmidi.

the latter one was not tested.
can anyone update the cvs if it works?


thanks.

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB recording - repetitive peaks

[Takashi Iwai]

Hi Patrick,

At Tue, 02 Jul 2002 23:28:08 +0900,
Patrick Shirkey wrote:
> 
> Thanks to your patch Takashi we have two people who have been able to 
> record through the quattro.
> 
> We have both found that there is a constant repetitive peak in the 
> signal which reminds me of the problems I had with the cmipci for a 
> brief period.
> 
> Thorsten Hass has recorded a perfect example for you which he did using 
> aplay and arecord. It is a sine wave so is easy on the ears.
> 
> http://www.thorstenhaas.de/alsa/audio.file
 
hmm, this sounds like the mismatching of packet size and copy
destination.  i heard your ogg file, and this was similar, too.

under which condition were they recorded?
with 24bit/96kHz/2ch?
or does it happen generally on every condition?

you can see the running status and condition on streamX proc file
during playback/capture.


> He has also generated a jpeg plotted by an oscilloscope while recording 
> which I can send you if it will help.

can you figure out how long the period of puls is?
i guess this has relation between the status shown in the proc file
above.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:
> Hi Patrick,
> 
> At Tue, 02 Jul 2002 23:28:08 +0900,
> Patrick Shirkey wrote:
> 
>>Thanks to your patch Takashi we have two people who have been able to 
>>record through the quattro.
>>
>>We have both found that there is a constant repetitive peak in the 
>>signal which reminds me of the problems I had with the cmipci for a 
>>brief period.
>>
>>Thorsten Hass has recorded a perfect example for you which he did using 
>>aplay and arecord. It is a sine wave so is easy on the ears.
>>
>>http://www.thorstenhaas.de/alsa/audio.file
> 
>  
> hmm, this sounds like the mismatching of packet size and copy
> destination.  i heard your ogg file, and this was similar, too.
> 
> under which condition were they recorded?
> with 24bit/96kHz/2ch?
> or does it happen generally on every condition?
> 

They were arecord -f cd

> you can see the running status and condition on streamX proc file
> during playback/capture.
> 

----
# cat /proc/asound/card2/stream1
M Audio USB AudioSport Quattro (tm) : USB Audio #1

Playback:
   Status: Stop
   Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 88200, 96000

Capture:
   Status: Running
     Packets = 20
     URBs = 5
     Packet Size = 192
     Nominal freq = 44.          1682  Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 88200, 96000

----


> 
> 
>>He has also generated a jpeg plotted by an oscilloscope while recording 
>>which I can send you if it will help.
> 
> 
> can you figure out how long the period of puls is?

They are so regular you can set a use them as a metronome:) Would you 
like me to have a look at the timing in an editor or is there an more 
precise way to find out?

> i guess this has relation between the status shown in the proc file
> above.
> 
> 
> Takashi
> 
> 



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB recording - repetitive peaks

[Takashi Iwai]

Hi Patrick,

i found out an obvious bug there.  i forgot to correct the offset
value of capture destination after a minor modification.
it's fixed on cvs.
could you update the cvs and test whether it works?


Takashi


At Wed, 03 Jul 2002 00:35:03 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > Hi Patrick,
> > 
> > At Tue, 02 Jul 2002 23:28:08 +0900,
> > Patrick Shirkey wrote:
> > 
> >>Thanks to your patch Takashi we have two people who have been able to 
> >>record through the quattro.
> >>
> >>We have both found that there is a constant repetitive peak in the 
> >>signal which reminds me of the problems I had with the cmipci for a 
> >>brief period.
> >>
> >>Thorsten Hass has recorded a perfect example for you which he did using 
> >>aplay and arecord. It is a sine wave so is easy on the ears.
> >>
> >>http://www.thorstenhaas.de/alsa/audio.file
> > 
> >  
> > hmm, this sounds like the mismatching of packet size and copy
> > destination.  i heard your ogg file, and this was similar, too.
> > 
> > under which condition were they recorded?
> > with 24bit/96kHz/2ch?
> > or does it happen generally on every condition?
> > 
> 
> They were arecord -f cd
> 
> > you can see the running status and condition on streamX proc file
> > during playback/capture.
> > 
> 
> ----
> # cat /proc/asound/card2/stream1
> M Audio USB AudioSport Quattro (tm) : USB Audio #1
> 
> Playback:
>    Status: Stop
>    Altset 3
>      Format: S16_LE
>      Channels: 2
>      Endpoint: 3 OUT (ADAPTIVE)
>      Rates: 11025, 22050, 44100, 48000
>    Altset 2
>      Format: S24_3LE
>      Channels: 2
>      Endpoint: 3 OUT (ADAPTIVE)
>      Rates: 11025, 22050, 44100, 48000
>    Altset 1
>      Format: S24_3LE
>      Channels: 2
>      Endpoint: 3 OUT (ADAPTIVE)
>      Rates: 88200, 96000
> 
> Capture:
>    Status: Running
>      Packets = 20
>      URBs = 5
>      Packet Size = 192
>      Nominal freq = 44.          1682  Altset 3
>      Format: S16_LE
>      Channels: 2
>      Endpoint: 5 IN (SYNC)
>      Rates: 11025, 22050, 44100, 48000
>    Altset 2
>      Format: S24_3LE
>      Channels: 2
>      Endpoint: 5 IN (SYNC)
>      Rates: 11025, 22050, 44100, 48000
>    Altset 1
>      Format: S24_3LE
>      Channels: 2
>      Endpoint: 5 IN (SYNC)
>      Rates: 88200, 96000
> 
> ----
> 
> 
> > 
> > 
> >>He has also generated a jpeg plotted by an oscilloscope while recording 
> >>which I can send you if it will help.
> > 
> > 
> > can you figure out how long the period of puls is?
> 
> They are so regular you can set a use them as a metronome:) Would you 
> like me to have a look at the timing in an editor or is there an more 
> precise way to find out?
> 
> > i guess this has relation between the status shown in the proc file
> > above.
> > 
> > 
> > Takashi
> > 
> > 
> 
> 
> 
> -- 
> Patrick Shirkey - Boost Hardware Ltd.
> For the discerning hardware connoisseur
> Http://www.boosthardware.com
> Http://www.boosthardware.com/LAU/guide/
> ========================================
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Patrick Shirkey wrote:
> 
> They are so regular you can set a use them as a metronome:) Would you 
> like me to have a look at the timing in an editor or is there an more 
> precise way to find out?
> 

36.5720 -> 36.5820

0.3710 -> 0.7430 -> 1.1140

Looking at the wave in an editor at almost 1:1 the distance between 
peaks is the above. There are mini peaks every 10ms and there are large 
peaks every 37.10 ms.







-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:
> Hi Patrick,
> 
> i found out an obvious bug there.  i forgot to correct the offset
> value of capture destination after a minor modification.
> it's fixed on cvs.
> could you update the cvs and test whether it works?
> 

I get this in alsa-utils

----
/usr/local/src/music/alsa/alsa-utils# ./cvscompile 
--with-cards=intel8x0,cmipci,usb-audio,usb-midi 
--with-sequencer=yes;make;make install
aclocal: configure.in: 11: macro `AM_PATH_ALSA' not found in library
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr//share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:11: error: possibly undefined macro: AM_PATH_ALSA
configure.in:28: error: possibly undefined macro: AM_CONFIG_HEADER
CFLAGS=-O2 -Wall -pipe -g
./configure --with-cards=intel8x0,cmipci,usb-audio,usb-midi 
--with-sequencer=yes
./configure: line 922: syntax error near unexpected token 
`AM_INIT_AUTOMAKE(alsa-utils,'
./configure: line 922: `AM_INIT_AUTOMAKE(alsa-utils, 0.9.0rc2)'
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

----

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Wed, 03 Jul 2002 01:37:30 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > Hi Patrick,
> > 
> > i found out an obvious bug there.  i forgot to correct the offset
> > value of capture destination after a minor modification.
> > it's fixed on cvs.
> > could you update the cvs and test whether it works?
> > 
> 
> I get this in alsa-utils
> 
> ----
> /usr/local/src/music/alsa/alsa-utils# ./cvscompile 
                            ^^^^^^^^^^
shouldn't be alsa-driver?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:
> At Wed, 03 Jul 2002 01:37:30 +0900,
> Patrick Shirkey wrote:
> 
>>Takashi Iwai wrote:
>>
>>>Hi Patrick,
>>>
>>>i found out an obvious bug there.  i forgot to correct the offset
>>>value of capture destination after a minor modification.
>>>it's fixed on cvs.
>>>could you update the cvs and test whether it works?
>>>
>>
>>I get this in alsa-utils
>>
>>----
>>/usr/local/src/music/alsa/alsa-utils# ./cvscompile 
> 
>                             ^^^^^^^^^^
> shouldn't be alsa-driver?
> 

Yeah I had to zap the cvs because of the patch confusing things so I'm 
trying to install alsa-utils but I get that error. alsa-driver and 
alsa-lib installed correctly.

Another thing is that even though I can rmmod all the other sound 
modules for other cards I cannot rmmod the following. I have checked 
with ps -aux that there are no stray processes. Currently I have to 
reboot. I think this only started with the new patches for recording.

snd-usb-audio          23136   1  (autoclean)
snd-pcm                48320   1  [snd-usb-audio]
snd-timer               9280   0  [snd-pcm]
snd                    23400   3  [snd-usb-audio snd-pcm snd-timer]
soundcore               3556   0  [snd]





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Wed, 03 Jul 2002 02:08:13 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 03 Jul 2002 01:37:30 +0900,
> > Patrick Shirkey wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >>>Hi Patrick,
> >>>
> >>>i found out an obvious bug there.  i forgot to correct the offset
> >>>value of capture destination after a minor modification.
> >>>it's fixed on cvs.
> >>>could you update the cvs and test whether it works?
> >>>
> >>
> >>I get this in alsa-utils
> >>
> >>----
> >>/usr/local/src/music/alsa/alsa-utils# ./cvscompile 
> > 
> >                             ^^^^^^^^^^
> > shouldn't be alsa-driver?
> > 
> 
> Yeah I had to zap the cvs because of the patch confusing things so I'm 
> trying to install alsa-utils but I get that error. alsa-driver and 
> alsa-lib installed correctly.

for alsa-utils you don't need any configure arguments.

the error message suggests that you didn't make install on alsa-lib.
please check whether /usr/share/aclocal/alsa.m4 exists.


> Another thing is that even though I can rmmod all the other sound 
> modules for other cards I cannot rmmod the following. I have checked 
> with ps -aux that there are no stray processes. Currently I have to 
> reboot. I think this only started with the new patches for recording.
> 
> snd-usb-audio          23136   1  (autoclean)
> snd-pcm                48320   1  [snd-usb-audio]
> snd-timer               9280   0  [snd-pcm]
> snd                    23400   3  [snd-usb-audio snd-pcm snd-timer]
> soundcore               3556   0  [snd]

this is weird.
there has been no fundamental change about this.
please try the following

	# fuser -k /dev/snd/* /dev/dsp* /dev/mixer*


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

 >the error message suggests that you didn't make install on alsa-lib.
 >please check whether /usr/share/aclocal/alsa.m4 exists.

I did run make install and have just done so again to make sure but it's 
not in /usr/local/share/aclocal either. I will copy it over and try 
recording again (see below).

Also I get this for snd-usb-midi
----
# modprobe snd-usb-midi
/lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: unresolved 
symbol snd_virmidi_new_Rc7dd286c
/lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: insmod 
/lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o failed
/lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: insmod 
snd-usb-midi failed
----

I just tried recording using the new code and completely hung the 
computer where only alt+sysreq+b worked. That was during recording.

The other person who is debugging with me has experienced simlilar as a 
kernel oops. He is currently using the patch to cvs but he will update 
soon I think.

This is what he said:
----
2) Kernel Oops:
The compilation of the source was rather a nice thing. I build some RPMs 
from
yesterdays snapshot to be able to clean up things after I installed them.
After installing, configuring modules.conf and removing my old 
asound.conf the
module probed finely.
I attached a copy of the aoutput of "arecord -l"

Recording was a bit messy, due to killing the arecord process freezes my 
box.
Deterministically: whenever the process is interuppted (Ctrl-C) or killed
(sig 9).
I attached a copy of the kernel-oops.


Oops: 0002

CPU:    0

EIP:    0010:[<d40c824a>]

EFLAGS: 00010002

eax: 000000b0   ebx: d16bfc00   ecx: 0000002c   edx: d45f4950

esi: d16bfc00   edi: 00002cc8   ebp: 0000002c   esp: c02e5e78

ds: 0018   es: 0018   ss: 0018

Process swapper (pid: 0, stackpage=c02e5000)

Stack: d45f4950 d45f49c0 d4cc19a0 d3efe5e0 00004000 00000000 00000004 
d40c8607

        d45f4950 d54a7c00 d3efe5e0 d3efe5e0 00000000 00000000 d3131e60 
d51b1f58

        d3efe5e0 00000246 d3efe5e0 d51b2660 d3efe5e0 d50f6800 04000001 
d89d8000

Call Trace: [<d40c8607>] [<d51b1f58>] [<d51b2660>] [<d51b3260>] 
[<c010814e>]

    [<c01082ae>] [<c010a118>] [<c01ad465>] [<c01ad2d4>] [<c0105407>] 
[<c0105000>]

    [<c0105027>]


Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 9c 59 fa 8b 5c 24 20

  <0>Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing


----





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Patrick Shirkey wrote:

> I did run make install and have just done so again to make sure but it's 
> not in /usr/local/share/aclocal either. I will copy it over and try 
> recording again (see below).
> 
> >
 >> Recording was a bit messy, due to killing the arecord process freezes my 
 >> box.
 >> Deterministically: whenever the process is interuppted (Ctrl-C) or killed
 >> (sig 9).

This seems to be the same here now. The file was recorded and with no 
distortions
to the sound but arecord hangs my rig when it stops. I'll check with 
JACK+ardour.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Patrick Shirkey wrote:
> Patrick Shirkey wrote:
> 
>> I did run make install and have just done so again to make sure but 
>> it's not in /usr/local/share/aclocal either. I will copy it over and 
>> try recording again (see below).
>>
>> >
> 
>  >> Recording was a bit messy, due to killing the arecord process 
> freezes my >> box.
>  >> Deterministically: whenever the process is interuppted (Ctrl-C) or 
> killed
>  >> (sig 9).
> 
> This seems to be the same here now. The file was recorded and with no 
> distortions
> to the sound but arecord hangs my rig when it stops. I'll check with 
> JACK+ardour.
> 
> 

Ouch. JACK+ardour causes an instant hang. Using alt+sysreq I can sync 
unmount and reboot but nothing else. Also the sound quality is 
significantly degraded while running through JACK. At least the native 
drivers are sounding correct now though :)



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Pedro Lopez-Cabanillas]

> - usb compatibility hack was moved to wrapper.h, so that it can be
>   shared with usbuadio.c
>
> - newly added virmidi registrations.
>   that means, snd-usb-midi will have its own rawmidi devices
>   automatically as /dev/snd/midiCxDx.
>   this will be good for applications which speak only with
>   rawmidi.
>
> the latter one was not tested.
> can anyone update the cvs if it works?
>

I can't compile current CVS usb drivers:

gcc -E -M -DALSA_BUILD -D__KERNEL__ -DMODULE=1 
-I/home/plc/kernelsrc/ALSA/cvstree/alsa-driver/include 
-I/lib/modules/2.4.18/build/include -O2 -mpreferred-stack-boundary=2 
-march=k6 -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -pipe  
usbaudio.c usbaudio.h usbmidi.c usbmixer.c wrapper.h > .depend
wrapper.h:1:40: missing binary operator before '<'
wrapper.h:15:40: missing binary operator before '<'
make[1]: *** [fastdep] Error 1

Pedro.



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: Re: [PATCH] USB MIDI driver

[Pedro Lopez-Cabanillas]

Me wrote:
>
> I can't compile current CVS usb drivers:
>
Sorry, It had been fixed 4 hours ago. 
I have compiled it succesfully now. And  also works! (only preliminary tests).

$ cat /proc/asound/seq/clients
Client info
  cur  clients : 5
  peak clients : 6
  max  clients : 192

Client   0 : "System" [Kernel]
  Port   0 : "Timer" (Rwe-)
  Port   1 : "Announce" (R-e-)
    Connecting To: 63:0
Client  63 : "OSS sequencer" [Kernel]
  Port   0 : "Receiver" (-we-)
    Connected From: 0:1
Client  64 : "External MIDI 0" [Kernel]
  Port   0 : "MIDI 0-0" (RWeX)
Client  72 : "EDIROL UM-2" [Kernel]
  Port   0 : "UM-2 Port 0" (RWeX)
    Connecting To: 80:0
  Port   1 : "UM-2 Port 1" (RWeX)
Client  80 : "Midiman Midisport 2x2" [Kernel]
  Port   0 : "Midisport 2x2 Port 0" (RWeX)
    Connected From: 72:0
  Port   1 : "Midisport 2x2 Port 1" (RWeX)

Thanks,
Pedro



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Fernando Pablo Lopez-Lezcano]

> I get this in alsa-utils
> 
> ----
> /usr/local/src/music/alsa/alsa-utils# ./cvscompile 
> --with-cards=intel8x0,cmipci,usb-audio,usb-midi 
> --with-sequencer=yes;make;make install
> aclocal: configure.in: 11: macro `AM_PATH_ALSA' not found in library
> /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
[MUNCH]

Same here from just downloaded CVS. 
I noticed that alsa-lib's make install did not install the alsa.m4 file...
Maybe it has something to do with this problem?
-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Tue, 2 Jul 2002 22:18:30 -0700 (PDT),
Fernando Pablo Lopez-Lezcano wrote:
> 
> > I get this in alsa-utils
> > 
> > ----
> > /usr/local/src/music/alsa/alsa-utils# ./cvscompile 
> > --with-cards=intel8x0,cmipci,usb-audio,usb-midi 
> > --with-sequencer=yes;make;make install
> > aclocal: configure.in: 11: macro `AM_PATH_ALSA' not found in library
> > /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> > /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> > /usr//share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> [MUNCH]
> 
> Same here from just downloaded CVS. 
> I noticed that alsa-lib's make install did not install the alsa.m4 file...
> Maybe it has something to do with this problem?

oh, yeah.  it happens on a new automake.
fixed now on cvs.


thanks,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Wed, 03 Jul 2002 03:04:39 +0900,
Patrick Shirkey wrote:
> 
>  >the error message suggests that you didn't make install on alsa-lib.
>  >please check whether /usr/share/aclocal/alsa.m4 exists.
> 
> I did run make install and have just done so again to make sure but it's 
> not in /usr/local/share/aclocal either. I will copy it over and try 
> recording again (see below).
> 
> Also I get this for snd-usb-midi
> ----
> # modprobe snd-usb-midi
> /lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: unresolved 
> symbol snd_virmidi_new_Rc7dd286c
> /lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: insmod 
> /lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o failed
> /lib/modules/2.4.19-rc1/kernel/sound/usb/snd-usb-midi.o: insmod 
> snd-usb-midi failed
> ----

fixed.

> 
> I just tried recording using the new code and completely hung the 
> computer where only alt+sysreq+b worked. That was during recording.
 
hmmm..  i'll check this.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Clemens Ladisch]

Takashi Iwai wrote:
> - newly added virmidi registrations.
>   that means, snd-usb-midi will have its own rawmidi devices
>   automatically as /dev/snd/midiCxDx.
>   this will be good for applications which speak only with
>   rawmidi.
> 
> the latter one was not tested.
> can anyone update the cvs if it works?

Using the cable number as index for the rawmidi device will not work
if there is more than one endpoint (I don't think such a device exists;
my driver supports more than one endpoint only because the OSS and
NetBSD drivers do).

I changed it to use the sequencer port number instead.

There are devices with more output than input ports (e.g. MU1000),
and virmidi with SNDRV_VIRMIDI_SEQ_ATTACH doesn't support input anyway,
so I moved the rmidi pointer from usbmidi_in_port to usbmidi_out_port.
(The virmidi device applies to both input and output ports, so,
theoretically, it should go into a usbmidi_endpoint structure. That
one hasn't been needed until now.)


Index: usbmidi.c
===================================================================
RCS file: /cvsroot/alsa/alsa-driver/usb/usbmidi.c,v
retrieving revision 1.1
diff -u -r1.1 usbmidi.c
--- usbmidi.c	2 Jul 2002 14:43:37 -0000	1.1
+++ usbmidi.c	3 Jul 2002 12:19:42 -0000
@@ -202,6 +202,7 @@
 	int nports;
 	struct usbmidi_out_port {
 		usbmidi_out_endpoint_t* ep;
+		snd_rawmidi_t *rmidi;
 		uint8_t cable;		/* cable number << 4 */
 		uint8_t sysex_len;
 		uint8_t sysex[2];
@@ -213,7 +214,6 @@
 	urb_t* urb;
 	struct usbmidi_in_port {
 		int seq_port;
-		snd_rawmidi_t *rmidi;
 		snd_midi_event_t* midi_event;
 	} ports[0x10];
 };
@@ -573,12 +573,9 @@
 		}
 		usb_free_urb(ep->urb);
 	}
-	for (i = 0; i < 0x10; ++i) {
+	for (i = 0; i < 0x10; ++i)
 		if (ep->ports[i].midi_event)
 			snd_midi_event_free(ep->ports[i].midi_event);
-		if (ep->ports[i].rmidi)
-			snd_device_free(ep->umidi->card, ep->ports[i].rmidi);
-	}
 	snd_magic_kfree(ep);
 }
 
@@ -695,6 +692,11 @@
  */
 static void snd_usbmidi_out_endpoint_delete(usbmidi_out_endpoint_t* ep)
 {
+	int i;
+
+	for (i = 0; i < ep->nports; ++i)
+		if (ep->ports[i].rmidi)
+			snd_device_free(ep->umidi->card, ep->ports[i].rmidi);
 	if (ep->tasklet.func)
 		tasklet_kill(&ep->tasklet);
 	if (ep->urb) {
@@ -789,13 +791,14 @@
 
 /*
  * After input and output endpoints have been initialized, create
- * the ALSA port for each input/output port pair.
+ * the ALSA port for each input/output port pair in the endpoint.
+ * *port_idx is the port number, which must be unique over all endpoints.
  */
 static int snd_usbmidi_create_endpoint_ports(usbmidi_t* umidi, int ep,
 					     int* port_idx)
 {
 	usbmidi_endpoint_info_t* ep_info = &umidi->device_info.endpoints[ep];
-	int c, out_port;
+	int c, out_port, err;
 	int cap, type, port;
 	int out, in;
 	snd_seq_port_callback_t port_callback;
@@ -813,7 +816,6 @@
 		if (out) {
 			port_callback.event_input = snd_usbmidi_port_input;
 			port_callback.private_data = &umidi->out_endpoints[ep]->ports[out_port];
-			++out_port;
 			cap |= SNDRV_SEQ_PORT_CAP_WRITE |
 				SNDRV_SEQ_PORT_CAP_SUBS_WRITE;	
 		}
@@ -828,7 +830,7 @@
 		type = SNDRV_SEQ_PORT_TYPE_MIDI_GENERIC;
 		/* TODO: read port name from jack descriptor */
 		sprintf(port_name, "%s Port %d",
-			umidi->device_info.product, (*port_idx)++);
+			umidi->device_info.product, *port_idx);
 		port = snd_seq_event_port_attach(umidi->seq_client,
 						 &port_callback,
 						 cap, type, port_name);
@@ -837,23 +839,27 @@
 		if (in)
 			umidi->in_endpoints[ep]->ports[c].seq_port = port;
 
-		if (c < SNDRV_MINOR_RAWMIDIS) {
+		if (out && *port_idx < SNDRV_MINOR_RAWMIDIS) {
 			snd_rawmidi_t *rmidi;
 			snd_virmidi_dev_t *rdev;
-			if (snd_virmidi_new(umidi->card, c, &rmidi) < 0)
-				continue;
-			umidi->in_endpoints[ep]->ports[c].rmidi = rmidi;
-			rdev = snd_magic_cast(snd_virmidi_dev_t, rmidi->private_data, continue);
+			err = snd_virmidi_new(umidi->card, *port_idx, &rmidi);
+			if (err < 0)
+				return err;
+			rdev = snd_magic_cast(snd_virmidi_dev_t, rmidi->private_data, return -ENXIO);
 			strcpy(rmidi->name, port_name);
 			rdev->seq_mode = SNDRV_VIRMIDI_SEQ_ATTACH;
 			rdev->client = umidi->seq_client;
 			rdev->port = port;
-			if (snd_device_register(umidi->card, rmidi) < 0) {
+			err = snd_device_register(umidi->card, rmidi);
+			if (err < 0) {
 				snd_device_free(umidi->card, rmidi);
-				continue;
+				return err;
 			}
-			umidi->in_endpoints[ep]->ports[c].rmidi = rmidi;
+			umidi->out_endpoints[ep]->ports[out_port].rmidi = rmidi;
 		}
+		if (out)
+			++out_port;
+		++*port_idx;
 	}
 	return 0;
 }


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Takashi Iwai]

At Wed, 03 Jul 2002 14:52:13 +0200,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > - newly added virmidi registrations.
> >   that means, snd-usb-midi will have its own rawmidi devices
> >   automatically as /dev/snd/midiCxDx.
> >   this will be good for applications which speak only with
> >   rawmidi.
> > 
> > the latter one was not tested.
> > can anyone update the cvs if it works?
> 
> Using the cable number as index for the rawmidi device will not work
> if there is more than one endpoint (I don't think such a device exists;
> my driver supports more than one endpoint only because the OSS and
> NetBSD drivers do).
> 
> I changed it to use the sequencer port number instead.
> 
> There are devices with more output than input ports (e.g. MU1000),
> and virmidi with SNDRV_VIRMIDI_SEQ_ATTACH doesn't support input anyway,

hmm, this mode wasn't tested, too.  usb-midi is the first case.
doesn't rawmidi read work at all?

> so I moved the rmidi pointer from usbmidi_in_port to usbmidi_out_port.
> (The virmidi device applies to both input and output ports, so,
> theoretically, it should go into a usbmidi_endpoint structure. That
> one hasn't been needed until now.)

yep. 


anyway, the patch is applied.  thanks.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > and virmidi with SNDRV_VIRMIDI_SEQ_ATTACH doesn't support input anyway,
> 
> hmm, this mode wasn't tested, too.  usb-midi is the first case.
> doesn't rawmidi read work at all?

The driver calls snd_seq_kernel_client_dispatch() to get rid of an event.
To receive a sequencer event, virmidi would need its own sequencer client
(or port), like it does with SNDRV_VIRMIDI_SEQ_DISPATCH, but then we would
have two sequencer clients.

Alternatively, usb-midi could call snd_virmidi_receive() directly, but that
smells somewhat like a hack. (I've noticed that snd_virmidi_receive() isn't
declared static, although it isn't exported either. :-)


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Wed, 03 Jul 2002 03:38:41 +0900,
Patrick Shirkey wrote:
> 
> Patrick Shirkey wrote:
> > Patrick Shirkey wrote:
> > 
> >> I did run make install and have just done so again to make sure but 
> >> it's not in /usr/local/share/aclocal either. I will copy it over and 
> >> try recording again (see below).
> >>
> >> >
> > 
> >  >> Recording was a bit messy, due to killing the arecord process 
> > freezes my >> box.
> >  >> Deterministically: whenever the process is interuppted (Ctrl-C) or 
> > killed
> >  >> (sig 9).
> > 
> > This seems to be the same here now. The file was recorded and with no 
> > distortions
> > to the sound but arecord hangs my rig when it stops. I'll check with 
> > JACK+ardour.
> > 
> > 
> 
> Ouch. JACK+ardour causes an instant hang. Using alt+sysreq I can sync 
> unmount and reboot but nothing else. Also the sound quality is 
> significantly degraded while running through JACK. At least the native 
> drivers are sounding correct now though :)

the hang-up at capture close was at least fixed on cvs.
it was due to the combination of ASYNC_UNLINK and complete callbacks. 

not sure whether the bug with jack is fixed, too, but i think it was
caused by the same reason.  please update the cvs tree.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Takashi Iwai]

At Wed, 03 Jul 2002 16:42:43 +0200,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > Clemens Ladisch wrote:
> > > and virmidi with SNDRV_VIRMIDI_SEQ_ATTACH doesn't support input anyway,
> > 
> > hmm, this mode wasn't tested, too.  usb-midi is the first case.
> > doesn't rawmidi read work at all?
> 
> The driver calls snd_seq_kernel_client_dispatch() to get rid of an event.
> To receive a sequencer event, virmidi would need its own sequencer client
> (or port), like it does with SNDRV_VIRMIDI_SEQ_DISPATCH, but then we would
> have two sequencer clients.

oh, yes, you're right.
 
> Alternatively, usb-midi could call snd_virmidi_receive() directly, but that
> smells somewhat like a hack. (I've noticed that snd_virmidi_receive() isn't
> declared static, although it isn't exported either. :-)

i think it's the easiest and cleanest way.
actually this was declared as external intentionally for such a
purpose, but just forgotten to be exported :)

i changed virmidi codes for easier use, and added
snd_virmidi_receive() to usbmidi.c.
could you check the updated driver?


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Clemens Ladisch]

Takashi Iwai wrote:
> i changed virmidi codes for easier use, and added
> snd_virmidi_receive() to usbmidi.c.
> could you check the updated driver?

It is obvious that you have not been able to check it.  :-)

My snd_usbmidi_port_input() function actually does the _output_ (I named
it 'input' because it began its life as the function to be assigend to
port_callback.event_input -- well, that's input _to_ the usb-midi port.
A better name for it would be snd_usbmidi_event_for_output).

The call to snd_virmidi_receive() should go into snd_usbmidi_input_packet.

And now it turns out that moving the rmidi pointer from the input to the
output endpoint structure was rather stupid by me because rmidi is needed
for input only. That change needs to be reverted, too.

The virmidi creation in snd_usbmidi_create_endpoint_ports should look like
the following: (warning: untested and made by hand because I don't have
access to my Linux box right now. patch probably won't accept those line
numbers! :-)


@@ at the end of snd_usbmidi_create_endpoint_ports
	if (in)
		umidi->in_endpoints[ep]->ports[c].seq_port = port;

-	if (out && *port_idx < SNDRV_MINOR_RAWMIDIS) {
+	if (in && *port_idx < SNDRV_MINOR_RAWMIDIS) {
		snd_rawmidi_t *rmidi;
		snd_virmidi_dev_t *rdev;
		err = snd_virmidi_new(umidi->card, *port_idx, &rmidi);
@@ a few lines later
			snd_device_free(umidi->card, rmidi);
			return err;
		}
-		umidi->out_endpoints[ep]->ports[out_port].rmidi = rmidi;
+		umidi->in_endpoints[ep]->ports[c].rmidi = rmidi;
	}
	if (out)
		++out_port;


This will not create virmidi ports for output only ports, but it should
actually work for the rest. :)

I think I'll be able to submit a patch for storing rmidi independently of
the input/output structures tomorrow.


Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:

 >the hang-up at capture close was at least fixed on cvs.
 >it was due to the combination of ASYNC_UNLINK and complete callbacks.
 >
 >not sure whether the bug with jack is fixed, too, but i think it was 
 >caused by the same reason.  please update the cvs tree.

I can now record successfully using arecord without hanging the system
but now I get an instant lock up while starting ardour. :( I have a 
suspicion that it happens when ardour registers with jackd and asks for 
the available input devices.  (I'm not sure about the sound quality. I 
will see if I can generate a test tone to use instead of actual music).

The only way to get out of it is reboot using sysreq.

I will check some more. Please note this wasn't happening so quickly 
yesterday.

I'm not sure about the sound quality it is definitely better. I will see 
if I can generate a test tone to use instead of actual music.

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Fri, 05 Jul 2002 01:23:18 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
>  >the hang-up at capture close was at least fixed on cvs.
>  >it was due to the combination of ASYNC_UNLINK and complete callbacks.
>  >
>  >not sure whether the bug with jack is fixed, too, but i think it was 
>  >caused by the same reason.  please update the cvs tree.
> 
> I can now record successfully using arecord without hanging the system
> but now I get an instant lock up while starting ardour. :( I have a 
> suspicion that it happens when ardour registers with jackd and asks for 
> the available input devices.  (I'm not sure about the sound quality. I 
> will see if I can generate a test tone to use instead of actual music).

then could you remove the mask USB_ASYNC_UNLINK from line 826 of
usbaudio.c? 
this might also leads to a lock-up when usb_submit_urb() fails, but
this must happen rarely.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:
> At Fri, 05 Jul 2002 01:23:18 +0900,
> Patrick Shirkey wrote:
> 
>>Takashi Iwai wrote:
>>
>> >the hang-up at capture close was at least fixed on cvs.
>> >it was due to the combination of ASYNC_UNLINK and complete callbacks.
>> >
>> >not sure whether the bug with jack is fixed, too, but i think it was 
>> >caused by the same reason.  please update the cvs tree.
>>
>>I can now record successfully using arecord without hanging the system
>>but now I get an instant lock up while starting ardour. :( I have a 
>>suspicion that it happens when ardour registers with jackd and asks for 
>>the available input devices.  (I'm not sure about the sound quality. I 
>>will see if I can generate a test tone to use instead of actual music).
> 
> 
> then could you remove the mask USB_ASYNC_UNLINK from line 826 of
> usbaudio.c? 
> this might also leads to a lock-up when usb_submit_urb() fails, but
> this must happen rarely.
> 

First I tried

		u->urb->transfer_flags = USB_ISO_ASAP; /*  |  USB_ASYNC_UNLINK; */

but that made almost no difference. I was able to load ardour for about 
10 seconds before the machine hung.

Now I have commented out the line and I get this from jackd

----
$ jackd -v -d alsa -d quattro2
jackd 0.37.1
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

2616 waiting for signals
creating alsa driver ... quattro2|1024|2|48000|swmon
new client: alsa_pcm, id = 1 type 1 @ 0x80664b0 fd = 12
port alsa_pcm:in_1 buf shm key 0x30945346 at offset 4096 bi = 0x8065880
registered port alsa_pcm:in_1, offset = 4096
port alsa_pcm:in_2 buf shm key 0x30945346 at offset 8192 bi = 0x8065890
registered port alsa_pcm:in_2, offset = 8192
registered port alsa_pcm:out_1, offset = 0
registered port alsa_pcm:out_2, offset = 0
-- jack_rechain_graph():
client alsa_pcm: inprocess client, execution_order=0.
ALSA: poll time out polled for 44800.813378
driver wait function failed, exiting
telling signal thread that the engine is done
jack main caught signal 1

----

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Paul Davis]

>client alsa_pcm: inprocess client, execution_order=0.
>ALSA: poll time out polled for 44800.813378
>driver wait function failed, exiting
>telling signal thread that the engine is done
>jack main caught signal 1

which means that the JACK alsa driver/client didn't return from poll
on the ALSA streams within the given timeout: ie. one or both of them
is not running.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Thorsten Haas]

Patrick, I'll checkout cvs tomorrow morning, compile and test around a bit 
with a rc-generator and the oscilloscope. I'll send the results to the list.

Am Donnerstag, 4. Juli 2002 18:23 schrieb Patrick Shirkey:
> Takashi Iwai wrote:
>  >the hang-up at capture close was at least fixed on cvs.
>  >it was due to the combination of ASYNC_UNLINK and complete callbacks.
>  >
>  >not sure whether the bug with jack is fixed, too, but i think it was
>  >caused by the same reason.  please update the cvs tree.
>
> I can now record successfully using arecord without hanging the system
> but now I get an instant lock up while starting ardour. :( I have a
> suspicion that it happens when ardour registers with jackd and asks for
> the available input devices.  (I'm not sure about the sound quality. I
> will see if I can generate a test tone to use instead of actual music).
>
> The only way to get out of it is reboot using sysreq.
>
> I will check some more. Please note this wasn't happening so quickly
> yesterday.
>
> I'm not sure about the sound quality it is definitely better. I will see
> if I can generate a test tone to use instead of actual music.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Thorsten Haas]

> > I'm not sure about the sound quality it is definitely better. I will see
> > if I can generate a test tone to use instead of actual music.

I checked out cvs this morning and compiled. I grabbed my function generator 
and fed my quattro usb with some signal; 400Hz, 0,7V peak-to-peak.

It's working finely now. (no more peaks)

I did the same thing some days before. ( Whoever is interested in the results 
and the output of the oscilloscope: http://www.thorstenhaas.de/alsa.php)




Am Donnerstag, 4. Juli 2002 20:59 schrieb Thorsten Haas:
> Patrick, I'll checkout cvs tomorrow morning, compile and test around a bit
> with a rc-generator and the oscilloscope. I'll send the results to the
> list.
>
> Am Donnerstag, 4. Juli 2002 18:23 schrieb Patrick Shirkey:
> > Takashi Iwai wrote:
> >  >the hang-up at capture close was at least fixed on cvs.
> >  >it was due to the combination of ASYNC_UNLINK and complete callbacks.
> >  >
> >  >not sure whether the bug with jack is fixed, too, but i think it was
> >  >caused by the same reason.  please update the cvs tree.
> >
> > I can now record successfully using arecord without hanging the system
> > but now I get an instant lock up while starting ardour. :( I have a
> > suspicion that it happens when ardour registers with jackd and asks for
> > the available input devices.  (I'm not sure about the sound quality. I
> > will see if I can generate a test tone to use instead of actual music).
> >
> > The only way to get out of it is reboot using sysreq.
> >
> > I will check some more. Please note this wasn't happening so quickly
> > yesterday.
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Clemens Ladisch]

I wrote:
> I think I'll be able to submit a patch for storing rmidi independently of
> the input/output structures tomorrow.

And here it is.

- moved rmidi to new structure usbmidi_endpoint
- moved call to snd_virmidi_receive to snd_usbmidi_input_packet
- renamed snd_usbmidi_port_input to snd_usbmidi_event_input
- removed dynamic allocation of usbmidi_out_port structures


Index: usbmidi.c
===================================================================
RCS file: /cvsroot/alsa/alsa-driver/usb/usbmidi.c,v
retrieving revision 1.3
diff -u -r1.3 usbmidi.c
--- usbmidi.c	4 Jul 2002 09:46:36 -0000	1.3
+++ usbmidi.c	5 Jul 2002 07:42:21 -0000
@@ -155,6 +155,7 @@
 typedef struct usbmidi usbmidi_t;
 typedef struct usbmidi_device_info usbmidi_device_info_t;
 typedef struct usbmidi_endpoint_info usbmidi_endpoint_info_t;
+typedef struct usbmidi_endpoint usbmidi_endpoint_t;
 typedef struct usbmidi_out_endpoint usbmidi_out_endpoint_t;
 typedef struct usbmidi_out_port usbmidi_out_port_t;
 typedef struct usbmidi_in_endpoint usbmidi_in_endpoint_t;
@@ -183,9 +184,11 @@
 	int dev;
 	int seq_client;
 	usbmidi_device_info_t device_info;
-
-	usbmidi_out_endpoint_t* out_endpoints[MAX_ENDPOINTS];
-	usbmidi_in_endpoint_t* in_endpoints[MAX_ENDPOINTS];
+	struct usbmidi_endpoint {
+		usbmidi_out_endpoint_t* out;
+		usbmidi_in_endpoint_t* in;
+		snd_rawmidi_t* rmidi[0x10];
+	} endpoints[MAX_ENDPOINTS];
 };
 
 struct usbmidi_out_endpoint {
@@ -199,18 +202,17 @@
 	int data_size;
 	spinlock_t buffer_lock;
 
-	int nports;
 	struct usbmidi_out_port {
 		usbmidi_out_endpoint_t* ep;
-		snd_rawmidi_t *rmidi;
 		uint8_t cable;		/* cable number << 4 */
 		uint8_t sysex_len;
 		uint8_t sysex[2];
-	} ports[0];
+	} ports[0x10];
 };
 
 struct usbmidi_in_endpoint {
 	usbmidi_t* umidi;
+	usbmidi_endpoint_t* ep;
 	urb_t* urb;
 	struct usbmidi_in_port {
 		int seq_port;
@@ -258,7 +260,8 @@
 	static const uint8_t cin_length[] = {
 		0, 0, 2, 3, 3, 1, 2, 3, 3, 3, 3, 3, 2, 2, 3, 1
 	};
-	usbmidi_in_port_t* port = &ep->ports[packet[0] >> 4];
+	int cable = packet[0] >> 4;
+	usbmidi_in_port_t* port = &ep->ports[cable];
 	snd_seq_event_t ev;
 
 	if (!port->midi_event)
@@ -271,6 +274,8 @@
 		ev.dest.client = SNDRV_SEQ_ADDRESS_SUBSCRIBERS;
 		snd_seq_kernel_client_dispatch(ep->umidi->seq_client,
 					       &ev, 1, 0);
+		if (ep->ep->rmidi[cable])
+			snd_virmidi_receive(ep->ep->rmidi[cable], &ev);
 	}
 }
 
@@ -454,8 +459,8 @@
 /*
  * Converts an ALSA sequencer event into USB MIDI packets.
  */
-static int snd_usbmidi_port_input(snd_seq_event_t* ev, int direct,
-				  void* private_data, int atomic, int hop)
+static int snd_usbmidi_event_input(snd_seq_event_t* ev, int direct,
+				   void* private_data, int atomic, int hop)
 {
 	usbmidi_out_port_t* port = (usbmidi_out_port_t*)private_data;
 	int err;
@@ -554,7 +559,6 @@
 	default:
 		return 0;
 	}
-	snd_virmidi_receive(port->rmidi, ev);
 	tasklet_hi_schedule(&port->ep->tasklet);
 	return 0;
 }
@@ -617,7 +621,7 @@
  */
 static int snd_usbmidi_in_endpoint_create(usbmidi_t* umidi,
 					  usbmidi_endpoint_info_t* ep_info,
-					  usbmidi_in_endpoint_t** rep)
+					  usbmidi_endpoint_t* rep)
 {
 	usbmidi_in_endpoint_t* ep;
 	int do_int_transfer;
@@ -626,11 +630,12 @@
 	unsigned int pipe;
 	int length, i, err;
 
-	*rep = NULL;
+	rep->in = NULL;
 	ep = snd_magic_kcalloc(usbmidi_in_endpoint_t, 0, GFP_KERNEL);
 	if (!ep)
 		return -ENOMEM;
 	ep->umidi = umidi;
+	ep->ep = rep;
 	for (i = 0; i < 0x10; ++i)
 		ep->ports[i].seq_port = -1;
 
@@ -674,7 +679,7 @@
 			}
 		}
 
-	*rep = ep;
+	rep->in = ep;
 	return 0;
 }
 
@@ -693,11 +698,6 @@
  */
 static void snd_usbmidi_out_endpoint_delete(usbmidi_out_endpoint_t* ep)
 {
-	int i;
-
-	for (i = 0; i < ep->nports; ++i)
-		if (ep->ports[i].rmidi)
-			snd_device_free(ep->umidi->card, ep->ports[i].rmidi);
 	if (ep->tasklet.func)
 		tasklet_kill(&ep->tasklet);
 	if (ep->urb) {
@@ -716,17 +716,15 @@
  */
 static int snd_usbmidi_out_endpoint_create(usbmidi_t* umidi,
 					   usbmidi_endpoint_info_t* ep_info,
-			 		   usbmidi_out_endpoint_t** rep)
+			 		   usbmidi_endpoint_t* rep)
 {
 	usbmidi_out_endpoint_t* ep;
-	int nports, i;
+	int i;
 	unsigned int pipe;
 	void* buffer;
 
-	*rep = NULL;
-	nports = snd_usbmidi_count_bits(ep_info->out_cables);
-	ep = snd_magic_kcalloc(usbmidi_out_endpoint_t,
-			       nports * sizeof(usbmidi_out_port_t), GFP_KERNEL);
+	rep->out = NULL;
+	ep = snd_magic_kcalloc(usbmidi_out_endpoint_t, 0, GFP_KERNEL);
 	if (!ep)
 		return -ENOMEM;
 	ep->umidi = umidi;
@@ -749,16 +747,13 @@
 	spin_lock_init(&ep->buffer_lock);
 	tasklet_init(&ep->tasklet, snd_usbmidi_out_tasklet, (unsigned long)ep);
 
-	ep->nports = nports;
-	nports = 0;
 	for (i = 0; i < 0x10; ++i)
 		if (ep_info->out_cables & (1 << i)) {
-			ep->ports[nports].ep = ep;
-			ep->ports[nports].cable = i << 4;
-			++nports;
+			ep->ports[i].ep = ep;
+			ep->ports[i].cable = i << 4;
 		}
 
-	*rep = ep;
+	rep->out = ep;
 	return 0;
 }
 
@@ -768,7 +763,7 @@
 static int snd_usbmidi_seq_device_delete(snd_seq_device_t* seq_device)
 {
 	usbmidi_t* umidi;
-	int i;
+	int i, j;
 
 	umidi = (usbmidi_t*)SNDRV_SEQ_DEVICE_ARGPTR(seq_device);
 
@@ -776,16 +771,21 @@
 		snd_seq_delete_kernel_client(umidi->seq_client);
 		umidi->seq_client = -1;
 	}
-
 	for (i = 0; i < MAX_ENDPOINTS; ++i) {
-		if (umidi->out_endpoints[i]) {
-			snd_usbmidi_out_endpoint_delete(umidi->out_endpoints[i]);
-			umidi->out_endpoints[i] = NULL;
-		}
-		if (umidi->in_endpoints[i]) {
-			snd_usbmidi_in_endpoint_delete(umidi->in_endpoints[i]);
-			umidi->in_endpoints[i] = NULL;
-		}
+		usbmidi_endpoint_t* ep = &umidi->endpoints[i];
+		if (ep->out) {
+			snd_usbmidi_out_endpoint_delete(ep->out);
+			ep->out = NULL;
+		}
+		if (ep->in) {
+			snd_usbmidi_in_endpoint_delete(ep->in);
+			ep->in = NULL;
+		}
+		for (j = 0; j < 0x10; ++j)
+			if (ep->rmidi[j]) {
+				snd_device_free(umidi->card, ep->rmidi[j]);
+				ep->rmidi[j] = NULL;
+			}
 	}
 	return 0;
 }
@@ -799,13 +799,12 @@
 					     int* port_idx)
 {
 	usbmidi_endpoint_info_t* ep_info = &umidi->device_info.endpoints[ep];
-	int c, out_port, err;
+	int c, err;
 	int cap, type, port;
 	int out, in;
 	snd_seq_port_callback_t port_callback;
 	char port_name[40];
 
-	out_port = 0;
 	for (c = 0; c < 0x10; ++c) {
 		out = ep_info->out_cables & (1 << c);
 		in = ep_info->in_cables & (1 << c);
@@ -815,8 +814,8 @@
 		memset(&port_callback, 0, sizeof(port_callback));
 		port_callback.owner = THIS_MODULE;
 		if (out) {
-			port_callback.event_input = snd_usbmidi_port_input;
-			port_callback.private_data = &umidi->out_endpoints[ep]->ports[out_port];
+			port_callback.event_input = snd_usbmidi_event_input;
+			port_callback.private_data = &umidi->endpoints[ep].out->ports[c];
 			cap |= SNDRV_SEQ_PORT_CAP_WRITE |
 				SNDRV_SEQ_PORT_CAP_SUBS_WRITE;	
 		}
@@ -838,9 +837,9 @@
 		if (port < 0)
 			return port;
 		if (in)
-			umidi->in_endpoints[ep]->ports[c].seq_port = port;
+			umidi->endpoints[ep].in->ports[c].seq_port = port;
 
-		if (out && *port_idx < SNDRV_MINOR_RAWMIDIS) {
+		if (*port_idx < SNDRV_MINOR_RAWMIDIS) {
 			snd_rawmidi_t *rmidi;
 			snd_virmidi_dev_t *rdev;
 			err = snd_virmidi_new(umidi->card, *port_idx, &rmidi);
@@ -856,10 +855,8 @@
 				snd_device_free(umidi->card, rmidi);
 				return err;
 			}
-			umidi->out_endpoints[ep]->ports[out_port].rmidi = rmidi;
+			umidi->endpoints[ep].rmidi[c] = rmidi;
 		}
-		if (out)
-			++out_port;
 		++*port_idx;
 	}
 	return 0;
@@ -879,13 +876,13 @@
 			continue;
 		if (ep_info->out_cables) {
 			err = snd_usbmidi_out_endpoint_create(umidi, ep_info,
-							      &umidi->out_endpoints[i]);
+							      &umidi->endpoints[i]);
 			if (err < 0)
 				return err;
 		}
 		if (ep_info->in_cables) {
 			err = snd_usbmidi_in_endpoint_create(umidi, ep_info,
-							     &umidi->in_endpoints[i]);
+							     &umidi->endpoints[i]);
 			if (err < 0)
 				return err;
 		}
@@ -936,8 +933,8 @@
 	}
 
 	for (i = 0; i < MAX_ENDPOINTS; ++i)
-		if (umidi->in_endpoints[i])
-			snd_usbmidi_submit_urb(umidi->in_endpoints[i]->urb,
+		if (umidi->endpoints[i].in)
+			snd_usbmidi_submit_urb(umidi->endpoints[i].in->urb,
 					       GFP_KERNEL);
 	return 0;
 }


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Thorsten Haas wrote:
>>>I'm not sure about the sound quality it is definitely better. I will see
>>>if I can generate a test tone to use instead of actual music.
>>
> 
> I checked out cvs this morning and compiled. I grabbed my function generator 
> and fed my quattro usb with some signal; 400Hz, 0,7V peak-to-peak.
> 
> It's working finely now. (no more peaks)
> 
> I did the same thing some days before. ( Whoever is interested in the results 
> and the output of the oscilloscope: http://www.thorstenhaas.de/alsa.php)
> 
>

That looks much better.

We still face the problem of accessing all 4 channels at once. AFAICT in 
the .asoundrc file the multi interface option does not have the ability 
to seperately access the channels in non sequential order. Therefore we 
are currently unable to access all the channels on the card because pcm0 
and pcm1 point to the same physical channels input 1 and input 2.

We need to either reorganise the pcm devices for the card or make it 
possible to secify channels in non sequential order using the multi 
interface option in a .asoundrc.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Thorsten Haas]

Am Freitag, 5. Juli 2002 10:34 schrieb Patrick Shirkey:
> Thorsten Haas wrote:
> >>>I'm not sure about the sound quality it is definitely better. I will see
> >>>if I can generate a test tone to use instead of actual music.
> >
> > I checked out cvs this morning and compiled. I grabbed my function
> > generator and fed my quattro usb with some signal; 400Hz, 0,7V
> > peak-to-peak.
> >
> > It's working finely now. (no more peaks)
> >
> > I did the same thing some days before. ( Whoever is interested in the
> > results and the output of the oscilloscope:
> > http://www.thorstenhaas.de/alsa.php)
>
> That looks much better.
>
> We still face the problem of accessing all 4 channels at once. AFAICT in
> the .asoundrc file the multi interface option does not have the ability
> to seperately access the channels in non sequential order. Therefore we
> are currently unable to access all the channels on the card because pcm0
> and pcm1 point to the same physical channels input 1 and input 2.
>
> We need to either reorganise the pcm devices for the card or make it
> possible to secify channels in non sequential order using the multi
> interface option in a .asoundrc.

I wish I was much more experienced in programming C++ and the structure of 
ALSA. Actually I am not. So I can hardly follow you what this will mean 
concerning effort and complexity.

So, what will it be?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Thorsten Haas]

I like to use two soundcards in my system.

I have an usb quattro and a trident compatible card. I read the manual at  
http://www.boosthardware.com/LAU/guide/ and configured modules.conf:#

------------------------- snip --------------------------------------
### NEW ALSA 0.9 from CVS 2002-07-05

##       General
# ALSA portion
  alias char-major-116 snd
# OSS/Free portion
  alias char-major-14 soundcore

##      Native Devices: ALSA portion
# quattro usb
  alias snd-card-0 snd-usb-audio
  options snd-usb-audio snd_index=0 snd_id="Q4"
# sis onboard (trident)
  alias snd-card-1 snd-card-trident
  options snd-card-trident snd_index=1 snd_id="SiS"

##      Native Devices: OSS/Free portion
# OSS Free Portion - Card 1 - quattro usb
  alias sound-slot-0 snd-card-0
  alias sound-service-0-0 snd-mixer-oss
  alias sound-service-0-1 snd-seq-oss
  alias sound-service-0-3 snd-pcm-oss
  alias sound-service-0-8 snd-seq-oss
  alias sound-service-0-12 snd-pcm-oss
# OSS Free Portion - Card 2 - Trident
  alias sound-slot-1 snd-card-1
  alias sound-service-1-0 snd-mixer-oss
  alias sound-service-1-3 snd-pcm-oss
  alias sound-service-1-12 snd-pcm-oss
------------------------- snap --------------------------------------

After that i ran depmod -a and tried

linda:~ # modprobe snd-card-trident
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_control_unregister_ioctl
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_switch_remove
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol snd_switch_free
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol snd_switch_add
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_switch_prepare
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_info_create_entry
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_control_register_ioctl
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol snd_switch_new
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 
snd_switch_free_one
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: insmod 
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o failed
/lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: insmod snd-card-trident failed

Can someone please give me ahint what I did wrong here?

Thorsten

PS: SORRY for the length.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] USB MIDI driver

[Takashi Iwai]

At Fri, 05 Jul 2002 09:55:27 +0200,
Clemens Ladisch wrote:
> 
> I wrote:
> > I think I'll be able to submit a patch for storing rmidi independently of
> > the input/output structures tomorrow.
> 
> And here it is.
> 
> - moved rmidi to new structure usbmidi_endpoint

ok, that's less confusing than before :)

> - moved call to snd_virmidi_receive to snd_usbmidi_input_packet
> - renamed snd_usbmidi_port_input to snd_usbmidi_event_input
> - removed dynamic allocation of usbmidi_out_port structures

thanks, now applied to cvs.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Fri, 05 Jul 2002 02:15:39 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 05 Jul 2002 01:23:18 +0900,
> > Patrick Shirkey wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >> >the hang-up at capture close was at least fixed on cvs.
> >> >it was due to the combination of ASYNC_UNLINK and complete callbacks.
> >> >
> >> >not sure whether the bug with jack is fixed, too, but i think it was 
> >> >caused by the same reason.  please update the cvs tree.
> >>
> >>I can now record successfully using arecord without hanging the system
> >>but now I get an instant lock up while starting ardour. :( I have a 
> >>suspicion that it happens when ardour registers with jackd and asks for 
> >>the available input devices.  (I'm not sure about the sound quality. I 
> >>will see if I can generate a test tone to use instead of actual music).
> > 
> > 
> > then could you remove the mask USB_ASYNC_UNLINK from line 826 of
> > usbaudio.c? 
> > this might also leads to a lock-up when usb_submit_urb() fails, but
> > this must happen rarely.
> > 
> 
> First I tried
> 
> 		u->urb->transfer_flags = USB_ISO_ASAP; /*  |  USB_ASYNC_UNLINK; */
> 
> but that made almost no difference. I was able to load ardour for about 
> 10 seconds before the machine hung.

i (hopefully) found the spot.
it happend when snd_pcm_stop() is called during complete callbacks, so
the working urb won't be released properly.
now the fixed version is on cvs.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Takashi Iwai]

At Fri, 5 Jul 2002 11:06:06 +0200,
Thorsten Haas wrote:
> 
> I like to use two soundcards in my system.
> 
> I have an usb quattro and a trident compatible card. I read the manual at  
> http://www.boosthardware.com/LAU/guide/ and configured modules.conf:#
> 
> ------------------------- snip --------------------------------------
> ### NEW ALSA 0.9 from CVS 2002-07-05
> 
> ##       General
> # ALSA portion
>   alias char-major-116 snd
> # OSS/Free portion
>   alias char-major-14 soundcore
> 
> ##      Native Devices: ALSA portion
> # quattro usb
>   alias snd-card-0 snd-usb-audio
>   options snd-usb-audio snd_index=0 snd_id="Q4"
> # sis onboard (trident)
>   alias snd-card-1 snd-card-trident
                     ^^^^^^^^^^^^^^^^  snd-trident

snd-card-xxx is an obsolete name for alsa 0.5.x.

>   options snd-card-trident snd_index=1 snd_id="SiS"
            ^^^^^^^^^^^^^^^^ here too


> After that i ran depmod -a and tried
> 
> linda:~ # modprobe snd-card-trident
> /lib/modules/2.4.10-4GB/misc/snd-rawmidi.o: unresolved symbol 

you have both alsa 0.5.x and 0.9.0 modules on the same kernel tree.
please remove old ones (snd-*.o) under /lib/modules/2.4.10-4GB/misc/.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Paul Davis wrote:
>>client alsa_pcm: inprocess client, execution_order=0.
>>ALSA: poll time out polled for 44800.813378
>>driver wait function failed, exiting
>>telling signal thread that the engine is done
>>jack main caught signal 1
> 
> 
> which means that the JACK alsa driver/client didn't return from poll
> on the ALSA streams within the given timeout: ie. one or both of them
> is not running.
> 

ie. I didn't have the card turned on :)

Just did it again and realised why.

> --p
> 
> 



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Takashi Iwai wrote:
> 
> i (hopefully) found the spot.
> it happend when snd_pcm_stop() is called during complete callbacks, so
> the working urb won't be released properly.
> now the fixed version is on cvs.
> 

Apparently not the g-spot.

I just tried using jack+ardour and the system hung again. This time it 
may have been triggered when I tried to switch virtual desktops. (I'm 
running enlightenment).

Everything was working (apart from peaks in the sound quality similar to 
the ones we were hearing natively only more pronounced). When I tried to 
switch into another part of the desktop everything hung.

I will try again because it may have been a time issue and therefore a 
complete coincidence.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: USB recording - repetitive peaks

[Patrick Shirkey]

Patrick Shirkey wrote:
> Takashi Iwai wrote:
> 
>>
>> i (hopefully) found the spot.
>> it happend when snd_pcm_stop() is called during complete callbacks, so
>> the working urb won't be released properly.
>> now the fixed version is on cvs.
>>
> 
> Apparently not the g-spot.
> 
> I just tried using jack+ardour and the system hung again. This time it 
> may have been triggered when I tried to switch virtual desktops. (I'm 
> running enlightenment).
> 
> Everything was working (apart from peaks in the sound quality similar to 
> the ones we were hearing natively only more pronounced). When I tried to 
> switch into another part of the desktop everything hung.
> 
> I will try again because it may have been a time issue and therefore a 
> complete coincidence.
> 
> 

It seems to be directly related to stress on xfree which causes an xrun 
in jackd.

This time when I started up I had a clear signal and could switch 
screens without dropouts but when I downloaded some messages I caused an 
xrun and then the sound got all choppy. Still no hang so I tried moving 
the ardour editor window to a different screen and that was it.

I have a usb mouse and am using the nvidia drivers for my video card 
which is a 64MB geforce2. Plus I was running jackd as normal user.

However I can get normal recording and xfree performance if I don't use 
jack. That is whether I am root user or not.

So it sounds like you have sorted the problem (unless you can think of 
anything else) and I need to do some serious fine tuning to get JACK 
working correctly.

We still need a way to access all four channels at the same time though.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf