Fwd: arecord bug?

Fwd: arecord bug?

[Jon Ellis]

Got bored waiting for a moderator...

Begin forwarded message:

> From: Jon Ellis <ashura666@mac.com>
> Date: Sat Mar 15, 2003  9:32:20  PM Japan
> To: alsa-devel@lists.sourceforge.net
> Subject: arecord bug?
>
> Hi,
>
> I'm the owner of this bug in gentoo:
>
> http://bugs.gentoo.org/show_bug.cgi?id=12724
>
>  and it's giving me grief because it takes so long to reproduce. The 
> basic problem is that either arecord or oggenc hangs after 400min 
> 47sec. The fact that lowering the sample rate (and talking to the ogg 
> devs) makes me think that this is a overflow somewhere in arecord.
>
> Does anyone have any clues as to where to start looking?
>
> Thanks
>
> j.
>



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Takashi Iwai]

At Tue, 18 Mar 2003 18:48:16 +0900,
Jon Ellis wrote:
> 
> Got bored waiting for a moderator...
> 
> Begin forwarded message:
> 
> > From: Jon Ellis <ashura666@mac.com>
> > Date: Sat Mar 15, 2003  9:32:20  PM Japan
> > To: alsa-devel@lists.sourceforge.net
> > Subject: arecord bug?
> >
> > Hi,
> >
> > I'm the owner of this bug in gentoo:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=12724
> >
> >  and it's giving me grief because it takes so long to reproduce. The 
> > basic problem is that either arecord or oggenc hangs after 400min 
> > 47sec. The fact that lowering the sample rate (and talking to the ogg 
> > devs) makes me think that this is a overflow somewhere in arecord.

i guess it reached to 32bit int limit (401*60*4*44100).
so far, aplay/arecord doesn't support more than size_t max, which is
32bit on i386.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Jon Ellis]

On Tuesday, March 18, 2003, at 10:29  PM, Takashi Iwai wrote:
>
> i guess it reached to 32bit int limit (401*60*4*44100).
> so far, aplay/arecord doesn't support more than size_t max, which is
> 32bit on i386.

Yep, that was my guess too. Is this something anyone is interested in 
fixing?

A couple of ideas:

i) move up to 64bits
ii) start using segments

If anyone who knows the code is interested in working with me i'd be 
happy to help find the right fix. Not sure that i have the time to 
learn the codebase from scratch right now...

Anyone?

j.



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Justin Cormack]

On Wed, 2003-03-19 at 09:49, Jon Ellis wrote:
> On Tuesday, March 18, 2003, at 10:29  PM, Takashi Iwai wrote:
> >
> > i guess it reached to 32bit int limit (401*60*4*44100).
> > so far, aplay/arecord doesn't support more than size_t max, which is
> > 32bit on i386.
> 
> Yep, that was my guess too. Is this something anyone is interested in 
> fixing?
> 
> A couple of ideas:
> 
> i) move up to 64bits
> ii) start using segments
> 
> If anyone who knows the code is interested in working with me i'd be 
> happy to help find the right fix. Not sure that i have the time to 
> learn the codebase from scratch right now...

Have you tried recompiling it with -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE in the CFLAGS? This should just work unless there is
somethong broken in the code.

Justin




-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Jon Ellis]

On Wednesday, March 19, 2003, at 09:08  PM, Justin Cormack wrote:

> On Wed, 2003-03-19 at 09:49, Jon Ellis wrote:
>> On Tuesday, March 18, 2003, at 10:29  PM, Takashi Iwai wrote:
>>>
>>> i guess it reached to 32bit int limit (401*60*4*44100).
>>> so far, aplay/arecord doesn't support more than size_t max, which is
>>> 32bit on i386.
>>
>> Yep, that was my guess too. Is this something anyone is interested in
>> fixing?
>>
>> A couple of ideas:
>>
>> i) move up to 64bits
>> ii) start using segments
>>
>> If anyone who knows the code is interested in working with me i'd be
>> happy to help find the right fix. Not sure that i have the time to
>> learn the codebase from scratch right now...
>
> Have you tried recompiling it with -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE in the CFLAGS? This should just work unless there 
> is
> somethong broken in the code.

i'll give it a try... my suspicion is that it wont work because it's 
the number of... er, frames (? I'm not sure i'm using the correct names 
for things) that is overflowing size_t. I'd be happy to be wrong.

j.



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Takashi Iwai]

At Wed, 19 Mar 2003 22:35:17 +0900,
Jon Ellis wrote:
> 
> On Wednesday, March 19, 2003, at 09:08  PM, Justin Cormack wrote:
> 
> > On Wed, 2003-03-19 at 09:49, Jon Ellis wrote:
> >> On Tuesday, March 18, 2003, at 10:29  PM, Takashi Iwai wrote:
> >>>
> >>> i guess it reached to 32bit int limit (401*60*4*44100).
> >>> so far, aplay/arecord doesn't support more than size_t max, which is
> >>> 32bit on i386.
> >>
> >> Yep, that was my guess too. Is this something anyone is interested in
> >> fixing?
> >>
> >> A couple of ideas:
> >>
> >> i) move up to 64bits
> >> ii) start using segments
> >>
> >> If anyone who knows the code is interested in working with me i'd be
> >> happy to help find the right fix. Not sure that i have the time to
> >> learn the codebase from scratch right now...
> >
> > Have you tried recompiling it with -D_FILE_OFFSET_BITS=64
> > -D_LARGEFILE_SOURCE in the CFLAGS? This should just work unless there 
> > is
> > somethong broken in the code.
> 
> i'll give it a try... my suspicion is that it wont work because it's 
> the number of... er, frames (? I'm not sure i'm using the correct names 
> for things) that is overflowing size_t. I'd be happy to be wrong.

it's the count in bytes.

anyway, i fixed the relevant part on cvs.
now arecord allows you to capture the unlimited size in the raw mode.
i've not tested this yet (no time :)

also fixed a bug in the capture to stdout in WAV mode.
it's restricted to 32bit signed int due to the RIFF chunk.  it would
be possible to record longer than creating more chunks but arecord
doesn't do that (yet).


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Jon Ellis]

On Wednesday, March 19, 2003, at 11:45  PM, Takashi Iwai wrote:

> At Wed, 19 Mar 2003 22:35:17 +0900,
> Jon Ellis wrote:
>>
>> i'll give it a try... my suspicion is that it wont work because it's
>> the number of... er, frames (? I'm not sure i'm using the correct 
>> names
>> for things) that is overflowing size_t. I'd be happy to be wrong.
>
> it's the count in bytes.
>
> anyway, i fixed the relevant part on cvs.
> now arecord allows you to capture the unlimited size in the raw mode.
> i've not tested this yet (no time :)

I'll get on the testing part and let you know if i can fill my disk ;-)

> also fixed a bug in the capture to stdout in WAV mode.
> it's restricted to 32bit signed int due to the RIFF chunk.  it would
> be possible to record longer than creating more chunks but arecord
> doesn't do that (yet).

Cool.

お力添えありがとうございます。 :-)

j.



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Kai Vehmanen]

On Tue, 18 Mar 2003, Jon Ellis wrote:

>> http://bugs.gentoo.org/show_bug.cgi?id=12724
[...]
>>  and it's giving me grief because it takes so long to reproduce. The 
>> basic problem is that either arecord or oggenc hangs after 400min 
>> 47sec. The fact that lowering the sample rate (and talking to the ogg 
>> devs) makes me think that this is a overflow somewhere in arecord.

If Takashi's guess is right and you are facing the 32bit problem, may I
suggest using ecasound:

ecasound -f:16,2,44100 -i alsa -o stdout |oggenc -r -q 0 -o recording.ogg -

Ecasound should be available as a Gentoo package. Be sure to compile
ecasound with --with-largefile.

As a bonus, you should get much more reliable recording thanks to
ecasound's double-buffering disk i/o subsystem and other mechanisms 
present to fight both disk i/o and scheduling latency spikes.

--
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Kai Vehmanen]

On Tue, 18 Mar 2003, Kai Vehmanen wrote:

> ecasound -f:16,2,44100 -i alsa -o stdout |oggenc -r -q 0 -o recording.ogg -

Btw; ecasound can also launch oggenc by itself. To modify oggenc params,
you have to edit ~/.ecasound/ecasoundrc (see man ecasoundrc(5) for info).
So the above command would be:

ecasound -f:16,2,44100 -i alsa -o recording.ogg

As another example, to get vu-meter while recording, you can issue:

ecasignalview -f:16,2,44100 alsa recording.ogg

Ecasignalview, too, comes with the standard ecasound package and thus
should be in Gentoo. If you prefer a GUI, try recording with:

ecamegapedal alsa recording.ogg

Independently of how you do the recording, you always get the benefits of
ecasound's realibility features. The key feature is separation of audio
and disk processing to separate execution contexts. If this is not done
(like is the case with arecord), any burst of disk activity can cause
xruns to the recording process.

--
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Fwd: arecord bug?

[Jon Ellis]

Thanks for the workaround.

Cheers

j.

On Tuesday, March 18, 2003, at 11:43  PM, Kai Vehmanen wrote:

> On Tue, 18 Mar 2003, Kai Vehmanen wrote:
>
>> ecasound -f:16,2,44100 -i alsa -o stdout |oggenc -r -q 0 -o 
>> recording.ogg -
>
> Btw; ecasound can also launch oggenc by itself. To modify oggenc 
> params,
> you have to edit ~/.ecasound/ecasoundrc (see man ecasoundrc(5) for 
> info).
> So the above command would be:
>
> ecasound -f:16,2,44100 -i alsa -o recording.ogg
>
> As another example, to get vu-meter while recording, you can issue:
>
> ecasignalview -f:16,2,44100 alsa recording.ogg
>
> Ecasignalview, too, comes with the standard ecasound package and thus
> should be in Gentoo. If you prefer a GUI, try recording with:
>
> ecamegapedal alsa recording.ogg
>
> Independently of how you do the recording, you always get the benefits 
> of
> ecasound's realibility features. The key feature is separation of audio
> and disk processing to separate execution contexts. If this is not done
> (like is the case with arecord), any burst of disk activity can cause
> xruns to the recording process.
>
> --
>  http://www.eca.cx
>  Audio software for Linux!
>



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en