Input gain on M-Audio Audiophile USB

Input gain on M-Audio Audiophile USB

[Richard Smith]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 596 bytes --]

Anybody have any idea how to change the line in input gain on the
M-Audio Audiophile USB?  The way its currently set renders it useless.
 It's just too hot.   If you connect any normal line level source up
to it it just bangs the input rails.

Alsamixer tells me there is not a mixer.

I know its possible because if you try the same setup under win2k then it works.

I've tried 1.0.9 and 1.0.10rc3 and they have the same behavior.

--
Richard A. Smith
N\x18¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰Ü\x0eŒ¨º
Þ¦Øk¢è!–ˆ\x1fŠW¬~Šé®†åzk\x12¶ŠC£	塧m…éÞÀ\x02@^Çš­È^ž\b§zØZ¶f¤zË\x1ej·!Šx2¢êå¢\aâ•ë\x1a±æ¬É«,º·âž\va{\a›\få,à\x03HòÔ4¨m¶ŸÿiÛ(±ÙÜ¢oÚv'

Re: Input gain on M-Audio Audiophile USB

[Pierre-Antoine Champin]

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

Richard Smith a écrit :
> Anybody have any idea how to change the line in input gain on the
> M-Audio Audiophile USB?  The way its currently set renders it useless.
>  It's just too hot.   If you connect any normal line level source up
> to it it just bangs the input rails.
> 
> Alsamixer tells me there is not a mixer.
> 
> I know its possible because if you try the same setup under win2k then it works.
> 
> I've tried 1.0.9 and 1.0.10rc3 and they have the same behavior.

I've not tried it recenrly, but the last time I did, I first thought I
had a gain problem, while this was actually a wrong byte order: it was
neither low-endian nor big-endian, but a strange mix, causing low-weight
values to be considered high-weight, hence the saturation impresson.

Filtering the input through a program which changes the order of the
bytes (a,b,c -> c,a,b) gives a good sound; but of course, it kills latency!

I attach the script I used to test that. I'm not sure this is the
problem you have, but it is worth a try.

  Pierre-Antoine



[-- Attachment #2: swap2.py --]
[-- Type: text/x-python, Size: 168 bytes --]

#!/usr/bin/python
import sys

while True:
    try:
        a,b,c = sys.stdin.read (3)
        sys.stdout.write ("".join ((c,a,b)))
    except ValueError:
        break

Re: Input gain on M-Audio Audiophile USB

[Richard Smith]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 851 bytes --]

On 12/5/05, Pierre-Antoine Champin <alsa-050822@champin.net> wrote:

> Filtering the input through a program which changes the order of the
> bytes (a,b,c -> c,a,b) gives a good sound; but of course, it kills latency!
>
> I attach the script I used to test that. I'm not sure this is the
> problem you have, but it is worth a try.

That appears to indeed be what the problem is.  Running your script on
the the output fixes it.
So it looks like recording on the Audiophile USB needs some endian
swaps.  This is probally a pretty easy thing to fix.

I'll try to dig into it tonight and have a look but in the mean time
anybody have any pointers on exactly where and what I should change?

--
Richard A. Smith
N\x18¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰Ü\x0eŒ¨º
Þ¦Øk¢è!–ˆ\x1fŠW¬~Šé®†åzk\x12¶ŠC£	塧m…éÞÀ\x02@^Çš­È^ž\b§zØZ¶f¤zË\x1ej·!Šx2¢êå¢\aâ•ë\x1a±æ¬É«,º·âž\va{\a›\få,à\x03HòÔ4¨m¶ŸÿiÛ(±ÙÜ¢oÚv'

Re: Input gain on M-Audio Audiophile USB

[Richard Smith]

> That appears to indeed be what the problem is.  Running your script on
> the the output fixes it.
> So it looks like recording on the Audiophile USB needs some endian
> swaps.  This is probally a pretty easy thing to fix.
>

My problems appear to go much deeper than endian issues.

I've come up with 4 different issues.  Every time I either boot or
power cycle / unplug the device I get  one of the following.  In all
cases the device will play fine if I use mpg321 and  '-o alsa09 -a
plughw'

Tested with 1.0.10rc1  on 2.6.14.2 and  1.0.10rc3 and 1.0.10  on
2.6.15-rc5-git1)

1) Device will not cpture at all

 $ arecord -vv -D hw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw

Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S24_3BE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 24
buffer_size  : 24000
period_size  : 6000
period_time  : 125000
tick_time    : 4000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 6000
xfer_align   : 6000
start_threshold  : 1
stop_threshold   : 24000
silence_threshold: 0
silence_size : 0
boundary     : 1572864000
arecord: pcm_read:1303: read error: Input/output error

2) Device captures but all I get is static.

 $ arecord -vv -D hw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw
 $ arecord -vv -D plughw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw

Both peg the VU meter with 99% and 100%
Using your swap2.py does not make any difference.

3) Device captures but all I get is silence.

 $ arecord -vv -D hw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw
 $ arecord -vv -D plughw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw

Both peg the VU meter with 99% and 100%
Using your swap2.py does not make any difference.

3) Device captures, VU meter shows max but its fixable.

 $ arecord -vv -D hw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw
 $ arecord -vv -D plughw:1,1 -f S24_3BE -t raw -c 2 -r48000 test.raw

Both peg the VU meter with 99% and 100%
Using swap2.py produces the proper audio with

 $ aplay -vv -D hw:1,0 -f S24_3BE -t raw -c 2 -r48000 test.swap

Like I said reboot, power cycle, unplug/replug the device and you get
one of the above.  I've been unable to determine any sort of pattern.

All of the above was done using a known line level source with no changes.

Should I file a bug or is there more stuff I can try.  I've not
enabled debug in the driver yet.

--
Richard A. Smith