Open-source USB interface: Audio Widget

[realmadrid]

I´m playing whit the AW in linux:
kernel 3.2.5
MPD 16.6
ALSA v1.0.25
Vortexbox 2.0.19
and the audio output format is always S24_3LE in UAC1 mode
and S32_LE in UAC2 mode. And I´m confused. Can someone explain the following outputs? I I think the format should be always S24_3LE .

UAC1

__________________________________________________ ___

Alsamixer v1.0.25 shows:

View: F3 PCM columm (audio output level no sensible to column level position)
__________________________________________________ _____

/card0/stream0 playing 16-44 wav file

DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio

Playback
Status: Running
Interface =3
Altset = 1
URBs = 3 [ 8 8 8 ]
Packet Size = 294
Momentary freq = 44102 Hz (0x2c.1a18)
Feedback Format = 10.14
Interface 3
Altset 1
Format: S24_3LE
Channel:2
Endpoint: 4 OUT (ASYNC)
Rates: 44100, 48000

Capture:
Status: Stop
Interface 4
Altset 1
Format:S24_3LE
Channels: 2
Endpoint: 5 IN (ASYNC)
Rates: 44100, 48000
__________________________________________________ _____

top shows:

USER %CPU %MEM COMMAND
root 0.3-1.0 0.9 mpd
Squeezb 0.7 3.2 squeezeserve
__________________________________________________ ______

hw_params shows:

access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
__________________________________________________ ______
__________________________________________________ ______


UAC2

__________________________________________________ _______

Alsamixer v1.0.25
Card: DG8SAQ-I2C
Chip: USB Mixer
Item: Clock2<->Clock 2 1 (no diff)
View: F3:[Playback]<Clock 2> Clock 2 1 F4: [Capture] This sound device does not have any... F5: [All] <Clock 2> Clock 2 1

__________________________________________________ ________

hw_params

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050

__________________________________________________ _________

/card0_stream0 plying the same file

DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio

Playback
Status: Runing
Interface = 2
Altset = 1
URBs = 8 [8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 44105 (0x5.8360)
Feedback Format = 15.17
Interface 2
Altset 1
Format = S32_LE
Channels: 2
Endpoint: 2 (OUT (ASYNC)
Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
Data Packet interval: 250 us
__________________________________________________ ___________
44100
USER %CPU %MEM COMMAND
root 07-1.0 0.7 mpd
squeezb ~1.0 3.3 squeezeboxserve
Format: S32_LE
__________________________________________________ ___________
24-44
root 1-2 0.7 mpd
squeezb 1-2 3.4 squeezeboxserve
Format: S32_LE
__________________________________________________ ___________
24-96
root 2-3 0.7 mpd
squeezb 2-3 3.4 squeezeboxserve
Format: S32_LE
__________________________________________________ ___________
24-88
root 2-3 0.6 mpd
squeezb 2-3 3.4 squeezeboxserve (some times higt noise on start,OK after pause/start)
Format: S32_LE
__________________________________________________ ____________
24-192
root 5 0.7 mpd
squeezb 4-5 3.3 squeezeboxserve
squeezb 6-7 0.1 sox (??????????, my comment)
squeezb 7-8 0.0 faad(??????????, my comemnt)
Format: S32_LE
__________________________________________________ _____________
24-192 (LINN Master)
root 6 0.6 mpd
squeezb 3-4 3.8 squeezeboxserve
Format: S32_LE
__________________________________________________ _____________

Thanks in advance
Juan

[alexlee188]

Hi Juan,

1. It is correct. uac1 the format is S24_LE and uac2 the format is S32_LE :-)

This is because we have changed the firmware to playback at 32 bits under uac2, for two reasons:

(a) For running the PCM5102 DAC which is 32 bits.
(b) For improved SQ even with the 24 bit ES9023 DAC. (as to why this is so please read the previous posts on this subject. Hint: 32bit i2s data is processed by the ES9023 internal DSP before sending to sigma-delta modulator (at 24 bit precision.)

We have not changed the uac1 from 24 bit to 32 bit. We don't plan to :-) The reasons are:

(a) users of the AW will be more interested in running it in uac2, to take advantage of the full capabilities;

(b) Nikolay is working on a Windows uac2 driver for the AW. We hope to have good news soon.

Alex

[alexlee188]

Hi Juan,

The current AW does not have hardware volume control so alsamixer under uac1 does not show any volume controllable GUI. The current versions of alsamixer does NOT support uac2 so you are seeing alsamixer trying to interpret uac2 descriptors as uac1 descriptors so it gets all confused.

We are planning future projects using DAC's that do have hardware volume control. We will address the GUI issue then. Until Linux alsamixer starts to support uac2, you can't use it to do volume control on uac2 devices. We may end up writing our own GUI to interact with the AW with volume control and other capabilities (see below).

A related issue is that uac2 has HID specifications to allow the hardware to notify the PC software of status changes etc. For example, if your audio device has a button for pause/play, then pressing the button will result in a HID message for the host PC, so that the host PC software can go into a pause/play mode correctly. We have not implemented that on the AW firmware as we are not sure of the uac2 HID support in Linux or Windows. Only OSX seems to have a full uac2 implementation at the moment.

Alex

[1audio]

Originally Posted by borges

Here is a draft sch and layout for the regulator which has been discussed here lately. Any comments?

I plan to put 3 such regulators on the AB-1.12 prototype board. The regulators will not be connected to other circuitry. It will be easy to patch them into points of load at the two XOs and at the DAC.

Børge

Please check on the power dissipation on the pass transistor Q2002. I would think 150 mA would be the max (the whole AB1.1 draws less than 250 mA). So 150 mA X 1.7V = 255 mW. I don't want anyone to have unpleasant smoke appearing so you may need a larger package and some PCB heatsinking.

[realmadrid]

Thanks Alex for the explanations.

So, the outputs are OK according the limitations of linux UAC2 implementation, ALSA, MPD, .... etc.... etc.
I´l accept that, but my idea about UAC2 on linux was that that was full implemented and transparent

Google servs me:
"_____________________
Most Linux players will send 16 bit data to the soundcard for 16 bit material and 24 bit data for 24 bit material.
Where the soundcard's native format differs from what an application sends, ALSA converts to the target format.
On my card, playing 24 bit material, mplayer sends 24 bit samples to ALSA and ALSA sends S32_LE data to the card (which is the only format the ICE1712 supports).

You can force the format that ALSA sends to the sound card by editing your .asoundrc.
I recommend you do this with KAsound, if you have KDE.
_______________________"
After that i will leave linux and try osx or freeBSD, waiting for Nicolay´s UAC2 for Windows.

So long linux, and thanks for all the fish.

Thanks again, Alex

Juan

[Turbon]

You'll be back Juan...

I have been doing it for soon 20 years, left tired of not finding info and tired of depending on developers not able to explain more than to other developers.
This is the backside of free OS'es. They surely have their place in the toolbox but you need to know more than you might want to learn. Otherwise when it is in place it works very, very well - until someone gets a bright idea and you have to redo parts of your learning and system.

Fun? Yes, it was but now it's not as exiting it used to be. OSX is calling and maybe soon Windows as well.

I hope more attention should be given to real UAC2 implementation by the book and not customize the widget to mainly fit the one or another OS. Stick to UAC2!

Brgds

[rsdio]

Originally Posted by Turbon

I hope more attention should be given to real UAC2 implementation by the book and not customize the widget to mainly fit the one or another OS. Stick to UAC2!

I agree.

For one thing, there is nothing lacking from UAC2 as a standard. As far as I know, there are no complaints about UAC2 other than lack of support. But there is no need to change the standard just because support is lacking, because a different standard is only going to be even less supported.

Second, anyone willing to create a custom driver for a small-time standard should simply put those same efforts into creating a UAC2 driver. It should be no more difficult to create a driver for a new protocol than for UAC2, so why create a new protocol if it doesn't really solve anything?

Finally, I am bothered that many of the alternatives to UAC2 are based on Bulk rather than Isochronous. The problem here is that basing an audio protocol on Bulk means that audio transfers have no guaranteed bandwidth on the USB, and thus any USB storage device could take over the available bandwidth and make the audio glitch. USB may not be the best family of specifications in the history of computers, but they got at least one thing right for audio when they specified guaranteed Isochronous bandwidth. In fact, USB itself only has four types of transfers, and Isochronous was created specifically to address the needs of real-time streams that cannot afford to drop out at random when other data flows burst to higher levels.

[alexlee188]

Hi rsdio et al,

I think you did not realize what I posted about the Windows uac2 driver for the AW that Nikolay is developing.

It IS a UAC2 driver. It is ISOCHRONOUS. It follows the uac2 specs.

btw, both the AW firmware and the forthcoming Windows uac2 driver are fully UAC2 specs compliant.

What may not be apparent to many people is that there are ambiguities in the UAC2 specs. Different OS driver implementations then can interprete the uac2 specs differently, leading to minor incompatibilities. The rate feedback format is one of these ambiquities. So OSX is not out of specs. So Linux uac2 driver is not out of specs. But they are different !!!

Also, don't confuse what I said about alsamixer with uac2 driver. Alsamixer does NOT use the uac2 driver. The uac2 driver for audio playback is working fine with the AW (except the quirks with rate feedback format which I explained above). Alsamixer (written by a different team from the uac2 driver) just has not been upgraded to uac2 yet. (btw, it was a similar situation wrt lsusb. The old lsusb does not know about uac2 and so it will list warnings and errors when parsing a uac2 device. The newer lsusb versions has updated uac2 parsing and are showing uac2 device descriptors correctly.

I don't want to get into arguments about which OS is "better". It becomes a "religious" issue and to each its own.

When it comes to standards, it is naive to believe that if everyone follows the standards, all will be fine. In the real world, there will be quirks and workarounds. Only if your are a big monopoly can you dictate that everyone else has to work according to your interpretation of the "standard".

Alex

[1audio]

UAC2 seems to be pretty complete and capable. The implementation on Linux is pretty new and seems to work mostly. There are a few bugs I suspect and some of it is different from the OSX implementation. The Windows implementations will be interesting to explore since they may all be different. There are rumors of a native implementation in Win 8 but no real evidence yet.

If we can identify real bug or implementation issues I'm sure that getting them fixed on Linux will be possible. OSX is quite the unknown right now and there are only a few Windows driver in the field. The Thesycon is the most commpon. Tenor has one for their chip, TE8802L, which is mostly UAC2 compliant. There are some other drivers on the horizon. If I can get a chance to test them I will.

[linuxworks]

freebsd? lol!

I ran a bsd shop for a long time and was pretty hard-headed about it, too. this was 10 yrs ago while linux was still a little young and bsd was very polished.

I have to say, its the opposite now. bsd is not well supported on a lot of hardware, its still the road much less travelled and a lot of core developers left. I'm not sure bsd has anything to offer anymore (I used to care about zfs but even that is not really cool since sun went out of business and oracle took over.)

I'm just amazed you'd think that life on the bsd side is any better.