On Sun, May 08, 2011 at 08:18:39PM +0200, Jan Stary wrote:
> On May 07 12:21:30, Alexandre Ratchov wrote:
> > On Sat, May 07, 2011 at 10:52:09AM +0200, Jan Stary wrote:
> > >
> > > I just bought me the "new" M-Audio USB MobilePre (MK-II):
> > >
> > > uaudio0 at uhub2 port 2 configuration 1 interface 0 "M-Audio MobilePre"
> > > rev 1.10/10.00 addr 2
> > > uaudio0: audio rev 1.00, 0 mixer controls
> > > audio0 at uaudio0
> > >
> > > Indeed, 'mixerctl -a' shows nothing; but
> > > aucat -u -C 0:1 -e s24le -r 48000 -o in.wav
> > > seems to be recording anyway (and the sound
> > > is very good).
> >
> > Cool.
>
> Is it OK for an uaudio(4) device to have 0 mixer controls?
> I can control the respective inputs/outputs with the device's (hardware)
> knobs, but having 0 (software) mixerctl variables still seems a bit strange.
> Is it possible that the device really has 0 controls to expose via USB
> audio (and uaudio just correctly reports that), or is this a sign that
> the dovice is not fully supported (or possibly not class-compliant)?
>
There might be software knobs not exposed by the driver. But I
wouldn't be completely surprised if there are none. They are not
necessary on a device that already has hardware knobs.
> > FWIW, above command will convert everything to 16-bit, and then
> > back to 24-bit, truncating lower 8 bits. To record 24-bit with no
> > precision loss, you have to recompile aucat in 24-bit mode.
> >
> > make COPTS=-DADATA_BITS=24
>
> Thank you. Is this documented somewhere?
>
not yet, I'll probably try to write a faq entry when I get some free
time.
Basically COPTS=-DADATA_BITS=24 switches aucat's internal
representation of samples from 16-bit to 24-bit integers. Since aucat
defaults are such that no format conversions are required, default
precision of files becomes 24-bit. So:
aucat -o file.wav
will generate a 24-bit file unless '-e s16' is specified. That's the
only difference.
> Is the 24bit functionality still considered experimental?
>
It's not experimental, I use it daily since around 6 months it's only
disabled because it cannot coexist with 16-bit mode yet. I mean we
can't have the same binary using 16-bit and 24-bit processing yet.
> I was trying to somehow 'test' that the device really can record 24bit
> samples as advertised (that's why I bought it). Running
>
> aucat -u -C 0:1 -e s24le -r 48000 -o in.wav
>
> records a 24bit file all right; anyway, the running aucat server
> (aucat -l) would resample/reformat for me even if the device could
> not do 24b/48kHz, right?
Yes, it will work on 16-bit devices, and 16-bit apps will still
work. BTW, that's the setup on my audio machines, it behaves as
before, except that it uses more cpu.
> So I killed the aucat server and run the
> above command again, resulting in a 24bit file again. Would the
> aucat command (without aucat -l running) also resample/reformat
> into the desired format even of the device cannot do it?
>
Yes. Server and non-server commands are the same, except that the
server dynamically creates streams by accepting connections, while
non-server commands use streams provided on the command line
(files). But the processing is the same.
> I very much doubt that this is the correct way to find out of course.
> What would be the correct way to find out what the device can physically do?
> All I know about is .../cap.c somewhere in the audio source tree. Is there
> a 'real' tool, exposed and documented?
>
There's no tool to explore capabilities mostly by lack of time and
motivation. I often use -ddd to see what the precision is:
$ aucat -ddd -r 48000 -f sun:0
sun:0: recording s24le4msb,0:1,48000
sun:0: playing s24le4msb,0:1,48000
...
This shows that the device is doing 24-bit stereo at 48kHz. The same
for a 16-bit card gives:
$ aucat -ddd -r 48000 -f sun:1
sun:1: recording s16le,0:1,48000
sun:1: playing s16le,0:1,48000
...
-- Alexandre
