SoX - Sound eXchange

On Sat, 16 Oct 2004, Juan Domenech wrote:
>sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>
>You can read the details at the bottom of this page
>http://www.domenech.org/bt878a-adc/alsa-e.htm

ugh, should that be:

sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav

Note the rate is 44.8k and not 448k?  And signed word is "-s -w" not
"-sw".  The '-t .wav' or even '-t wav' is optional, since sox should be
able to detect the output format from the filename extension.

Let me know if this command line works...

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

On this topic, I just submited patches to CVS to define __user and 
__kernel as nothing.

Now I can compile alsa.c under Fedora Core 3 Test 3.

So I then tried to run "sox monkey.wav -s -w -r 44100 -t alsa
/dev/pcmC0D0p".  I also get the  ioctl fail with 22 (invalid parameter).

The OSS emulation works fine to /dev/dsp... 
Hmmm... Not sure what the problem is.

Unfortunetly, if its like the OSS driver, the only real way to figure
out the problem is to split up the setting of each parameter to
seperate ioctl()'s to see whats failing (ie. set signed words in
one, rate in another, etc).  Not sure if ALSA lends it self to
that very well.  I'll leave that to another day.

Chris

On Sun, Oct 17, 2004 at 04:34:10PM -1000, Jimen Ching wrote:
> On Sat, 16 Oct 2004, Juan Domenech wrote:
> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >
> >You can read the details at the bottom of this page
> >http://www.domenech.org/bt878a-adc/alsa-e.htm
> 
> ugh, should that be:
> 
> sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav
> 
> Note the rate is 44.8k and not 448k?  And signed word is "-s -w" not
> "-sw".  The '-t .wav' or even '-t wav' is optional, since sox should be
> able to detect the output format from the filename extension.
> 
> Let me know if this command line works...
> 
> --jc
> -- 
> Jimen Ching (WH6BRR)      jching@...     wh6brr@...
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Sox-users mailing list
> Sox-users@...
> https://lists.sourceforge.net/lists/listinfo/sox-users

-- 
 Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
          http://www.cnpbagwell.com/             |         USA

On Mon, 18 Oct 2004, Chris Bagwell wrote:
>Unfortunetly, if its like the OSS driver, the only real way to figure
>out the problem is to split up the setting of each parameter to
>seperate ioctl()'s to see whats failing (ie. set signed words in
>one, rate in another, etc).  Not sure if ALSA lends it self to
>that very well.  I'll leave that to another day.

An easy thing to do would be to print out the contents of 'setup' inside
alsa_hw_info_set() (this should be easy to do from gdb).  Make sure all of
the parameters have sane values.  I use whatever the driver reports.  But
it might report invalid values, depending on how well written it is.
Since it works with some boards and not others, this implies there's
something specific to the drivers.

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

I was testing on a laptop with the intel i8x0 driver.  This chipset
is always coming up on bugreports on Fedora+alsa for what ever reason.

It does have a few issues that have to be dealt with manually.
For instance, it only supports rates of 48000, not 44100.  OSS
driver handles this by allowing a + or - range of rates to be
set (it plays 44100 audio at 48000).  Its not ideal but is what
most other apps, like xmms, do as well.

I'll try the gdb thing when I have some more time.

Chris

On Mon, Oct 18, 2004 at 09:54:40PM -1000, Jimen Ching wrote:
> On Mon, 18 Oct 2004, Chris Bagwell wrote:
> >Unfortunetly, if its like the OSS driver, the only real way to figure
> >out the problem is to split up the setting of each parameter to
> >seperate ioctl()'s to see whats failing (ie. set signed words in
> >one, rate in another, etc).  Not sure if ALSA lends it self to
> >that very well.  I'll leave that to another day.
> 
> An easy thing to do would be to print out the contents of 'setup' inside
> alsa_hw_info_set() (this should be easy to do from gdb).  Make sure all of
> the parameters have sane values.  I use whatever the driver reports.  But
> it might report invalid values, depending on how well written it is.
> Since it works with some boards and not others, this implies there's
> something specific to the drivers.
>

On Tue, 19 Oct 2004, Chris Bagwell wrote:
>It does have a few issues that have to be dealt with manually.
>For instance, it only supports rates of 48000, not 44100.  OSS
>driver handles this by allowing a + or - range of rates to be
>set (it plays 44100 audio at 48000).  Its not ideal but is what
>most other apps, like xmms, do as well.

So, I assume you've tried the 48000 rate and it also fails?

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

Hi,

Here you have more tests:

SoX with ALSA and my old "Creative ViBRA16C pnp". Works perfect.

[root@... root]# sox -V -w -c 1 -r 44100 -t alsa /dev/snd/pcmC0D0c -t =
.wav test.wav
sox: Input file /dev/snd/pcmC0D0c: using sample rate 44100
        size shorts, encoding signed (2's complement), 1 channel
sox: Input file /dev/snd/pcmC0D0c: comment "/dev/snd/pcmC0D0c"
=20
sox: Writing Wave file: Microsoft PCM format, 1 channel, 44100 samp/sec
sox:         88200 byte/sec, 2 block align, 16 bits/samp
sox: Output file test.wav: using sample rate 44100
        size shorts, encoding signed (2's complement), 1 channel
sox: Output file: comment "/dev/snd/pcmC0D0c"
 =20
sox: Finished writing Wave file, 196608 data bytes 98304 samples



But there is no way to make the Bt878a to work.

[root@... root]# sox -V -b -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t =
.wav test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -w -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t =
.wav test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -w -c 2 -r 448000 -t alsa /dev/snd/pcmC1D1c -t =
.wav test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22


And default sample rate:

[root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav =
test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22


The conclusion is clear: There is some problem with the Bt878 driver. =
It's strange because with the native arecord utility works well.=20

I'll try to activate some kind of debug into the driver.

I'll keep you posted.

Bye.



Juan Domenech


----- Original Message -----=20
From: "Chris Bagwell" <chris@...>
To: "Jimen Ching" <jching@...>
Cc: "Juan Domenech" <jdf@...>; <sox-users@...>
Sent: Tuesday, October 19, 2004 4:02 AM
Subject: Re: [SoX-users] SoX under ALSA and the Bt878a


> On this topic, I just submited patches to CVS to define __user and=20
> __kernel as nothing.
>=20
> Now I can compile alsa.c under Fedora Core 3 Test 3.
>=20
> So I then tried to run "sox monkey.wav -s -w -r 44100 -t alsa
> /dev/pcmC0D0p".  I also get the  ioctl fail with 22 (invalid =
parameter).
>=20
> The OSS emulation works fine to /dev/dsp...=20
> Hmmm... Not sure what the problem is.
>=20
> Unfortunetly, if its like the OSS driver, the only real way to figure
> out the problem is to split up the setting of each parameter to
> seperate ioctl()'s to see whats failing (ie. set signed words in
> one, rate in another, etc).  Not sure if ALSA lends it self to
> that very well.  I'll leave that to another day.
>=20
> Chris
>=20
> On Sun, Oct 17, 2004 at 04:34:10PM -1000, Jimen Ching wrote:
>> On Sat, 16 Oct 2004, Juan Domenech wrote:
>> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>> >
>> >You can read the details at the bottom of this page
>> >http://www.domenech.org/bt878a-adc/alsa-e.htm
>>=20
>> ugh, should that be:
>>=20
>> sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav
>>=20
>> Note the rate is 44.8k and not 448k?  And signed word is "-s -w" not
>> "-sw".  The '-t .wav' or even '-t wav' is optional, since sox should =
be
>> able to detect the output format from the filename extension.
>>=20
>> Let me know if this command line works...
>>=20
>> --jc
>> --=20
>> Jimen Ching (WH6BRR)      jching@...     wh6brr@...
>>=20
>>=20
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on =
ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. =
Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find =
out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Sox-users mailing list
>> Sox-users@...
>> https://lists.sourceforge.net/lists/listinfo/sox-users
>=20
> --=20
> Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
>          http://www.cnpbagwell.com/             |         USA
>

On Thu, 21 Oct 2004, Juan Domenech wrote:
>The conclusion is clear: There is some problem with the Bt878 driver.
>It's strange because with the native arecord utility works well.

If arecord works, then there could be a bug in the sox handler for ALSA.
I'll take a look at it this weekend.

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

On Thu, 21 Oct 2004, Juan Domenech wrote:
>[root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
>sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>
>The conclusion is clear: There is some problem with the Bt878 driver.
>It's strange because with the native arecord utility works well.

Chris, Juan,

I've took a look at the arecord (aplay) source code and there seems to be
only one relevant change.  The attached patch comments out the setting of
the 'periods'.  Can you guys try it out?

--jc

P.S. Juan, were you able to record with the exact same parameters with
arecord?  The source code seems to limit the sample rate to 192000.  So
your 488000 would cause an error.

-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

WooHoo, I was able to get sox playing on my laptop with the alsa driver!

Actually, your patch wasn't needed.  Please let me know if you think
it should be commited to CVS or not after hearing about the list
of changes I've already made below.

My problem was related to sample channels/rate/size/encoding... All at once.
For some reason, the ALSA OSS emulation handles a lot larger range of
formats/rates/channels then the ALSA driver... Go figure.

Anyways, I did as you suggested and looked at a_info and compared it
to what was being setup in a_setup.  That structure showed that
my driver only supports 2 channels minimum... There was a missing
check to reduce the number of channels to minimum (but the max
was there).

Next, the check to reduce min sample rates was doing a *2 for some
reason... That made the new rate go over the maximum.  I removed the *2.

Next, my hardware/driver only appears to support 16-bit signed words.
The get_format() function didn't have any concept of overriding
values to a supported format like the oss.c does.  So I added in
some code to do that.

Now I can play monkey.wav (a-law 8-bit 8000 rate included with sox) and some
16-bit 48000 ogg's without specifying any command line flags.
So it turns out my audio hardware really is only good (I say that
very lossly) at playing 16-bit signed data at high sample rates.

And last up, although I can play monkey.wav by issuing
"sox monkey.wav -t alsa /dev/snd/pcmC0D0p", I can not actually
hear any audio come out.  That audio file is 0.2 seconds long and so
its kinda like a few buffers are being thrown aware by ALSA at
the beginning of playing... Longer audio files play fine.

I'll leave this one for a future debug session.

Chris

On Sat, Oct 23, 2004 at 08:28:55AM -1000, Jimen Ching wrote:
> On Thu, 21 Oct 2004, Juan Domenech wrote:
> >[root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >
> >The conclusion is clear: There is some problem with the Bt878 driver.
> >It's strange because with the native arecord utility works well.
> 
> Chris, Juan,
> 
> I've took a look at the arecord (aplay) source code and there seems to be
> only one relevant change.  The attached patch comments out the setting of
> the 'periods'.  Can you guys try it out?

Jaun,

If your comfortable with CVS, could you download the latest version
of sox and try it out?  I think it will probably work with
both cards now.

As Jimen said though, the sample rate your using may be an issue.

Chris

On Thu, Oct 21, 2004 at 09:15:41PM +0200, Juan Domenech wrote:
> Hi,
> 
> Here you have more tests:
> 
> SoX with ALSA and my old "Creative ViBRA16C pnp". Works perfect.
> 
> [root@... root]# sox -V -w -c 1 -r 44100 -t alsa /dev/snd/pcmC0D0c -t .wav test.wav
> sox: Input file /dev/snd/pcmC0D0c: using sample rate 44100
>         size shorts, encoding signed (2's complement), 1 channel
> sox: Input file /dev/snd/pcmC0D0c: comment "/dev/snd/pcmC0D0c"
>  
> sox: Writing Wave file: Microsoft PCM format, 1 channel, 44100 samp/sec
> sox:         88200 byte/sec, 2 block align, 16 bits/samp
> sox: Output file test.wav: using sample rate 44100
>         size shorts, encoding signed (2's complement), 1 channel
> sox: Output file: comment "/dev/snd/pcmC0D0c"
>   
> sox: Finished writing Wave file, 196608 data bytes 98304 samples
> 
> 
> 
> But there is no way to make the Bt878a to work.
> 
> [root@... root]# sox -V -b -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -w -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -w -c 2 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> 
> And default sample rate:
> 
> [root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> 
> The conclusion is clear: There is some problem with the Bt878 driver. It's strange because with the native arecord utility works well. 
> 
> I'll try to activate some kind of debug into the driver.
> 
> I'll keep you posted.
> 
> Bye.
> 
> 
> 
> Juan Domenech
> 
> 
> ----- Original Message ----- 
> From: "Chris Bagwell" <chris@...>
> To: "Jimen Ching" <jching@...>
> Cc: "Juan Domenech" <jdf@...>; <sox-users@...>
> Sent: Tuesday, October 19, 2004 4:02 AM
> Subject: Re: [SoX-users] SoX under ALSA and the Bt878a
> 
> 
> > On this topic, I just submited patches to CVS to define __user and 
> > __kernel as nothing.
> > 
> > Now I can compile alsa.c under Fedora Core 3 Test 3.
> > 
> > So I then tried to run "sox monkey.wav -s -w -r 44100 -t alsa
> > /dev/pcmC0D0p".  I also get the  ioctl fail with 22 (invalid parameter).
> > 
> > The OSS emulation works fine to /dev/dsp... 
> > Hmmm... Not sure what the problem is.
> > 
> > Unfortunetly, if its like the OSS driver, the only real way to figure
> > out the problem is to split up the setting of each parameter to
> > seperate ioctl()'s to see whats failing (ie. set signed words in
> > one, rate in another, etc).  Not sure if ALSA lends it self to
> > that very well.  I'll leave that to another day.
> > 
> > Chris
> > 
> > On Sun, Oct 17, 2004 at 04:34:10PM -1000, Jimen Ching wrote:
> >> On Sat, 16 Oct 2004, Juan Domenech wrote:
> >> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> >
> >> >You can read the details at the bottom of this page
> >> >http://www.domenech.org/bt878a-adc/alsa-e.htm
> >> 
> >> ugh, should that be:
> >> 
> >> sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav
> >> 
> >> Note the rate is 44.8k and not 448k?  And signed word is "-s -w" not
> >> "-sw".  The '-t .wav' or even '-t wav' is optional, since sox should be
> >> able to detect the output format from the filename extension.
> >> 
> >> Let me know if this command line works...
> >> 
> >> --jc
> >> -- 
> >> Jimen Ching (WH6BRR)      jching@...     wh6brr@...
> >> 
> >> 
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >> Use IT products in your business? Tell us what you think of them. Give us
> >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >> _______________________________________________
> >> Sox-users mailing list
> >> Sox-users@...
> >> https://lists.sourceforge.net/lists/listinfo/sox-users
> > 
> > -- 
> > Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
> >          http://www.cnpbagwell.com/             |         USA
> >
-- 
 Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
          http://www.cnpbagwell.com/             |         USA

On Sat, 23 Oct 2004, Chris Bagwell wrote:
>Actually, your patch wasn't needed.  Please let me know if you think
>it should be commited to CVS or not after hearing about the list
>of changes I've already made below.

Well, I've looked at the source code to aplay, and it commented out the
setting of 'period'.  If this change is not needed, then ignore it.

>Anyways, I did as you suggested and looked at a_info and compared it
>to what was being setup in a_setup.  That structure showed that
>my driver only supports 2 channels minimum... There was a missing
>check to reduce the number of channels to minimum (but the max
>was there).

This looks fine.

>Next, the check to reduce min sample rates was doing a *2 for some
>reason... That made the new rate go over the maximum.  I removed the *2.

I did this so the rate isn't too low.  I believe I saw the min rate go as
low as 4000.  So I doubled it to 8000.

>Next, my hardware/driver only appears to support 16-bit signed words.
>The get_format() function didn't have any concept of overriding
>values to a supported format like the oss.c does.  So I added in
>some code to do that.

I'm not sure I like the library overriding my parameters.  If I didn't
specify a setting, that's ok.  But if I wanted a specific value, then I'd
prefer the library error out.

>And last up, although I can play monkey.wav by issuing
>"sox monkey.wav -t alsa /dev/snd/pcmC0D0p", I can not actually
>hear any audio come out.  That audio file is 0.2 seconds long and so
>its kinda like a few buffers are being thrown aware by ALSA at
>the beginning of playing... Longer audio files play fine.

Could this be something with buffer_size/period_size?  I wasn't too
familiar with this parameters...

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

On Sun, Oct 24, 2004 at 12:14:41AM -1000, Jimen Ching wrote:
> >Next, my hardware/driver only appears to support 16-bit signed words.
> >The get_format() function didn't have any concept of overriding
> >values to a supported format like the oss.c does.  So I added in
> >some code to do that.
> 
> I'm not sure I like the library overriding my parameters.  If I didn't
> specify a setting, that's ok.  But if I wanted a specific value, then I'd
> prefer the library error out.

In general, I'm with you on this idea.  On the other side, most users
of sox just want "play soundfile" to work regardless of the datatype so
the override is needed somewhere.

Its best to push this up into the application (sox.c in this case) but
before we coud do that I think we'd need to provide a new interface
that applications can query supported data types for a given handler.
Without that, it just be an endless call to startwrite() until one just
happened to not error out.  I'll add this to the TODO list so that it
hopefully gets done one day.

> >And last up, although I can play monkey.wav by issuing
> >"sox monkey.wav -t alsa /dev/snd/pcmC0D0p", I can not actually
> >hear any audio come out.  That audio file is 0.2 seconds long and so
> >its kinda like a few buffers are being thrown aware by ALSA at
> >the beginning of playing... Longer audio files play fine.
> 
> Could this be something with buffer_size/period_size?  I wasn't too
> familiar with this parameters...

When I have more time I'll put some more break points and see if they
have reasonable values.

Chris

On Sun, Oct 24, 2004 at 03:20:20PM -0500, Chris Bagwell wrote:
> > >And last up, although I can play monkey.wav by issuing
> > >"sox monkey.wav -t alsa /dev/snd/pcmC0D0p", I can not actually
> > >hear any audio come out.  That audio file is 0.2 seconds long and so
> > >its kinda like a few buffers are being thrown aware by ALSA at
> > >the beginning of playing... Longer audio files play fine.
> > 
> > Could this be something with buffer_size/period_size?  I wasn't too
> > familiar with this parameters...

OK, found this problem.  st_alsastopwrite() was asking ALSA to flush
its partial buffers, then asking sox to flush its partial buffers.
The order of those two calls needed to be swapped.

Now monkey.wav plays correctly with alsa driver on my box.

Chris

Chris,

The problem persists. I've compiled the last version using CVS. Here are =
the tests:

[root@... root]# sox -V -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
sox: ALSA drive doesn't support (null) byte.  Changing to signed bytes.
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -w -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
sox: ALSA drive doesn't support (null) byte.  Changin to signed words.
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -sw -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -sw -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav =
test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

[root@... root]# sox -V -sw -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t =
.wav test.wav
sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22



Don't worry. I have a very peculiar sound card and I should try another =
approach. I'll try to use a program from a friend to do something like =
this:

err=3Dsnd_pcm_hw_params_set_access(record_handle,hw_params,SND_PCM_ACCESS=
_RW_INTERLEAVED);
if(err<0){printf("ADC cannot set access type (%s)\n",snd_strerror =
(err));exit (1);}

err=3Dsnd_pcm_hw_params_set_format(record_handle,hw_params,SND_PCM_FORMAT=
_S16_LE);
if(err<0){printf("ADC cannot set sample format (%s)\n",snd_strerror =
(err));exit (1);}

And so on. And find where the problem is.

I'll keep the list posted.

Thanks.


Juan Domenech


----- Original Message -----=20
From: "Chris Bagwell" <chris@...>
To: "Juan Domenech" <jdf@...>
Cc: "Jimen Ching" <jching@...>; <sox-users@...>
Sent: Sunday, October 24, 2004 2:58 AM
Subject: Re: [SoX-users] SoX under ALSA and the Bt878a


> Jaun,
>=20
> If your comfortable with CVS, could you download the latest version
> of sox and try it out?  I think it will probably work with
> both cards now.
>=20
> As Jimen said though, the sample rate your using may be an issue.
>=20
> Chris
>=20
> On Thu, Oct 21, 2004 at 09:15:41PM +0200, Juan Domenech wrote:
>> Hi,
>>=20
>> Here you have more tests:
>>=20
>> SoX with ALSA and my old "Creative ViBRA16C pnp". Works perfect.
>>=20
>> [root@... root]# sox -V -w -c 1 -r 44100 -t alsa /dev/snd/pcmC0D0c -t =
.wav test.wav
>> sox: Input file /dev/snd/pcmC0D0c: using sample rate 44100
>>         size shorts, encoding signed (2's complement), 1 channel
>> sox: Input file /dev/snd/pcmC0D0c: comment "/dev/snd/pcmC0D0c"
>> =20
>> sox: Writing Wave file: Microsoft PCM format, 1 channel, 44100 =
samp/sec
>> sox:         88200 byte/sec, 2 block align, 16 bits/samp
>> sox: Output file test.wav: using sample rate 44100
>>         size shorts, encoding signed (2's complement), 1 channel
>> sox: Output file: comment "/dev/snd/pcmC0D0c"
>>  =20
>> sox: Finished writing Wave file, 196608 data bytes 98304 samples
>>=20
>>=20
>>=20
>> But there is no way to make the Bt878a to work.
>>=20
>> [root@... root]# sox -V -b -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c =
-t .wav test.wav
>> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>>=20
>> [root@... root]# sox -V -w -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c =
-t .wav test.wav
>> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>>=20
>> [root@... root]# sox -V -w -c 2 -r 448000 -t alsa /dev/snd/pcmC1D1c =
-t .wav test.wav
>> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>>=20
>>=20
>> And default sample rate:
>>=20
>> [root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav =
test.wav
>> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>>=20
>>=20
>> The conclusion is clear: There is some problem with the Bt878 driver. =
It's strange because with the native arecord utility works well.=20
>>=20
>> I'll try to activate some kind of debug into the driver.
>>=20
>> I'll keep you posted.
>>=20
>> Bye.
>>=20
>>=20
>>=20
>> Juan Domenech
>>=20
>>=20
>> ----- Original Message -----=20
>> From: "Chris Bagwell" <chris@...>
>> To: "Jimen Ching" <jching@...>
>> Cc: "Juan Domenech" <jdf@...>; =
<sox-users@...>
>> Sent: Tuesday, October 19, 2004 4:02 AM
>> Subject: Re: [SoX-users] SoX under ALSA and the Bt878a
>>=20
>>=20
>> > On this topic, I just submited patches to CVS to define __user and=20
>> > __kernel as nothing.
>> >=20
>> > Now I can compile alsa.c under Fedora Core 3 Test 3.
>> >=20
>> > So I then tried to run "sox monkey.wav -s -w -r 44100 -t alsa
>> > /dev/pcmC0D0p".  I also get the  ioctl fail with 22 (invalid =
parameter).
>> >=20
>> > The OSS emulation works fine to /dev/dsp...=20
>> > Hmmm... Not sure what the problem is.
>> >=20
>> > Unfortunetly, if its like the OSS driver, the only real way to =
figure
>> > out the problem is to split up the setting of each parameter to
>> > seperate ioctl()'s to see whats failing (ie. set signed words in
>> > one, rate in another, etc).  Not sure if ALSA lends it self to
>> > that very well.  I'll leave that to another day.
>> >=20
>> > Chris
>> >=20
>> > On Sun, Oct 17, 2004 at 04:34:10PM -1000, Jimen Ching wrote:
>> >> On Sat, 16 Oct 2004, Juan Domenech wrote:
>> >> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
>> >> >
>> >> >You can read the details at the bottom of this page
>> >> >http://www.domenech.org/bt878a-adc/alsa-e.htm
>> >>=20
>> >> ugh, should that be:
>> >>=20
>> >> sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav
>> >>=20
>> >> Note the rate is 44.8k and not 448k?  And signed word is "-s -w" =
not
>> >> "-sw".  The '-t .wav' or even '-t wav' is optional, since sox =
should be
>> >> able to detect the output format from the filename extension.
>> >>=20
>> >> Let me know if this command line works...
>> >>=20
>> >> --jc
>> >> --=20
>> >> Jimen Ching (WH6BRR)      jching@...     wh6brr@...
>> >>=20
>> >>=20
>> >> -------------------------------------------------------
>> >> This SF.net email is sponsored by: IT Product Guide on =
ITManagersJournal
>> >> Use IT products in your business? Tell us what you think of them. =
Give us
>> >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find =
out more
>> >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> >> _______________________________________________
>> >> Sox-users mailing list
>> >> Sox-users@...
>> >> https://lists.sourceforge.net/lists/listinfo/sox-users
>> >=20
>> > --=20
>> > Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
>> >          http://www.cnpbagwell.com/             |         USA
>> >
> --=20
> Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
>          http://www.cnpbagwell.com/             |         USA
>

Two things to try...

1) Use /dev/snd/pcmC1D1p instead of "c"... Make any difference?
2) Try "-c 2"... My card only supports stereo audio.. But its at least
nice enough to report that as well so the new alsa.c detects it and
override to stereo mode.  Perhaps yours is mistakenly reporting it
supports mono.

Chris

On Tue, Oct 26, 2004 at 07:23:46PM +0200, Juan Domenech wrote:
> Chris,
> 
> The problem persists. I've compiled the last version using CVS. Here are the tests:
> 
> [root@... root]# sox -V -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: ALSA drive doesn't support (null) byte.  Changing to signed bytes.
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -w -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: ALSA drive doesn't support (null) byte.  Changin to signed words.
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -sw -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -sw -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> [root@... root]# sox -V -sw -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> 
> 
> Don't worry. I have a very peculiar sound card and I should try another approach. I'll try to use a program from a friend to do something like this:
> 
> err=snd_pcm_hw_params_set_access(record_handle,hw_params,SND_PCM_ACCESS_RW_INTERLEAVED);
> if(err<0){printf("ADC cannot set access type (%s)\n",snd_strerror (err));exit (1);}
> 
> err=snd_pcm_hw_params_set_format(record_handle,hw_params,SND_PCM_FORMAT_S16_LE);
> if(err<0){printf("ADC cannot set sample format (%s)\n",snd_strerror (err));exit (1);}
> 
> And so on. And find where the problem is.
> 
> I'll keep the list posted.
> 
> Thanks.
> 
> 
> Juan Domenech
> 
> 
> ----- Original Message ----- 
> From: "Chris Bagwell" <chris@...>
> To: "Juan Domenech" <jdf@...>
> Cc: "Jimen Ching" <jching@...>; <sox-users@...>
> Sent: Sunday, October 24, 2004 2:58 AM
> Subject: Re: [SoX-users] SoX under ALSA and the Bt878a
> 
> 
> > Jaun,
> > 
> > If your comfortable with CVS, could you download the latest version
> > of sox and try it out?  I think it will probably work with
> > both cards now.
> > 
> > As Jimen said though, the sample rate your using may be an issue.
> > 
> > Chris
> > 
> > On Thu, Oct 21, 2004 at 09:15:41PM +0200, Juan Domenech wrote:
> >> Hi,
> >> 
> >> Here you have more tests:
> >> 
> >> SoX with ALSA and my old "Creative ViBRA16C pnp". Works perfect.
> >> 
> >> [root@... root]# sox -V -w -c 1 -r 44100 -t alsa /dev/snd/pcmC0D0c -t .wav test.wav
> >> sox: Input file /dev/snd/pcmC0D0c: using sample rate 44100
> >>         size shorts, encoding signed (2's complement), 1 channel
> >> sox: Input file /dev/snd/pcmC0D0c: comment "/dev/snd/pcmC0D0c"
> >>  
> >> sox: Writing Wave file: Microsoft PCM format, 1 channel, 44100 samp/sec
> >> sox:         88200 byte/sec, 2 block align, 16 bits/samp
> >> sox: Output file test.wav: using sample rate 44100
> >>         size shorts, encoding signed (2's complement), 1 channel
> >> sox: Output file: comment "/dev/snd/pcmC0D0c"
> >>   
> >> sox: Finished writing Wave file, 196608 data bytes 98304 samples
> >> 
> >> 
> >> 
> >> But there is no way to make the Bt878a to work.
> >> 
> >> [root@... root]# sox -V -b -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> 
> >> [root@... root]# sox -V -w -c 1 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> 
> >> [root@... root]# sox -V -w -c 2 -r 448000 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> 
> >> 
> >> And default sample rate:
> >> 
> >> [root@... root]# sox -V -w -c 1 -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >> sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> 
> >> 
> >> The conclusion is clear: There is some problem with the Bt878 driver. It's strange because with the native arecord utility works well. 
> >> 
> >> I'll try to activate some kind of debug into the driver.
> >> 
> >> I'll keep you posted.
> >> 
> >> Bye.
> >> 
> >> 
> >> 
> >> Juan Domenech
> >> 
> >> 
> >> ----- Original Message ----- 
> >> From: "Chris Bagwell" <chris@...>
> >> To: "Jimen Ching" <jching@...>
> >> Cc: "Juan Domenech" <jdf@...>; <sox-users@...>
> >> Sent: Tuesday, October 19, 2004 4:02 AM
> >> Subject: Re: [SoX-users] SoX under ALSA and the Bt878a
> >> 
> >> 
> >> > On this topic, I just submited patches to CVS to define __user and 
> >> > __kernel as nothing.
> >> > 
> >> > Now I can compile alsa.c under Fedora Core 3 Test 3.
> >> > 
> >> > So I then tried to run "sox monkey.wav -s -w -r 44100 -t alsa
> >> > /dev/pcmC0D0p".  I also get the  ioctl fail with 22 (invalid parameter).
> >> > 
> >> > The OSS emulation works fine to /dev/dsp... 
> >> > Hmmm... Not sure what the problem is.
> >> > 
> >> > Unfortunetly, if its like the OSS driver, the only real way to figure
> >> > out the problem is to split up the setting of each parameter to
> >> > seperate ioctl()'s to see whats failing (ie. set signed words in
> >> > one, rate in another, etc).  Not sure if ALSA lends it self to
> >> > that very well.  I'll leave that to another day.
> >> > 
> >> > Chris
> >> > 
> >> > On Sun, Oct 17, 2004 at 04:34:10PM -1000, Jimen Ching wrote:
> >> >> On Sat, 16 Oct 2004, Juan Domenech wrote:
> >> >> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> >> >> >
> >> >> >You can read the details at the bottom of this page
> >> >> >http://www.domenech.org/bt878a-adc/alsa-e.htm
> >> >> 
> >> >> ugh, should that be:
> >> >> 
> >> >> sox -V -r 44800 -s -w -t alsa /dev/snd/pcmC1D1c -t wav test.wav
> >> >> 
> >> >> Note the rate is 44.8k and not 448k?  And signed word is "-s -w" not
> >> >> "-sw".  The '-t .wav' or even '-t wav' is optional, since sox should be
> >> >> able to detect the output format from the filename extension.
> >> >> 
> >> >> Let me know if this command line works...
> >> >> 
> >> >> --jc
> >> >> -- 
> >> >> Jimen Ching (WH6BRR)      jching@...     wh6brr@...
> >> >> 
> >> >> 
> >> >> -------------------------------------------------------
> >> >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >> >> Use IT products in your business? Tell us what you think of them. Give us
> >> >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >> >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >> >> _______________________________________________
> >> >> Sox-users mailing list
> >> >> Sox-users@...
> >> >> https://lists.sourceforge.net/lists/listinfo/sox-users
> >> > 
> >> > -- 
> >> > Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
> >> >          http://www.cnpbagwell.com/             |         USA
> >> >
> > -- 
> > Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
> >          http://www.cnpbagwell.com/             |         USA
> >
-- 
 Chris Bagwell <chris at cnpbagwell dot com>     |     Frisco, TX
          http://www.cnpbagwell.com/             |         USA

On Tue, 26 Oct 2004, Chris Bagwell wrote:
>1) Use /dev/snd/pcmC1D1p instead of "c"... Make any difference?

The 'c' is for capture, and the 'p' is for playback.  So that part of the
command line looks ok.  But I'm not sure about the -sw.  I thought support
for this syntax was removed?

>[root@... root]# sox -V -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
>sox: ALSA drive doesn't support (null) byte.  Changing to signed bytes.
>sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22

Also, I took a look at the changes to get_format.  Attached is a patch to
fix some typos.  I think the first if-statement of this function may be
redundant.  The second if-statement will catch the unset case, and code
further down the function will catch unsupported sizes.

The '(null)' output above looks like the ft->info.encoding isn't set.
Maybe it should be defaulted like ft->info.size.

--jc
-- 
Jimen Ching (WH6BRR)      jching@...     wh6brr@...

On Wed, Oct 27, 2004 at 10:35:12PM -1000, Jimen Ching wrote:
> >[root@... root]# sox -V -t alsa /dev/snd/pcmC1D1c -t .wav test.wav
> >sox: ALSA drive doesn't support (null) byte.  Changing to signed bytes.
> >sox: Failed reading /dev/snd/pcmC1D1c: ioctl operation failed 22
> 
> Also, I took a look at the changes to get_format.  Attached is a patch to
> fix some typos.  I think the first if-statement of this function may be
> redundant.  The second if-statement will catch the unset case, and code
> further down the function will catch unsupported sizes.

I combined the first size if() statements as much as possible now... It
fixed some array underflows (the (null) output you mentioned).

> The '(null)' output above looks like the ft->info.encoding isn't set.
> Maybe it should be defaulted like ft->info.size.

Thanks for catching that and the other typos... 

Chris