Re: Re: USB recording - repetitive peaks

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

[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: 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]

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: 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: 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: 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

[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

[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

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: 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: 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

[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

[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