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