Hi Alex,
I do not wish to dilute this thread, but if you have any links to details about the ambiguities in the UAC2 specifications, then please share.
I am well aware that Microsoft's lack of a complete USB-MIDI implementation on any of their operating systems dooms all viable hardware from fully implementing the specification, simply because a full implementation results in a device that will bomb under Windows. I am also aware that even in an ideal world where Windows did not ignore a complete implementation, there is still the fact that the USB-MIDI specification itself is sorely lacking in terms of accurate timing, and thus random latency plagues these devices.
In other words, I have no illusion that the UAC2 spec is perfect - I simply stated that I am not aware of any problems with the spec. Thus, I am very interested in learning more about the ambiguities that you allude to.
Thanks for any pointers.
Hi rsdio,
OK. This is a very technical subject and is very confusing. But I will just give some pointers and you can do more research
1. In UAC2 specs, page 40, section 3.16.2.2, it says the feedback format to " refer to Section 5.12.4.2, “Feedback” and Section 9.6.6, “Endpoint” in the USB Specification.
2. In the USB2.0 specs, page 73, section 5.12.4.2, it basically says the format should be:
10.14 for full-speed device and 16.16 for high speed device.
For full speed device, it should be per frame (ie 1 msec). For high speed device, it should be per uFrame (ie per 125us).
3. HOWEVER, there is no mention of what this per microframe is referring to. Is this the absolute per every 125us realtime clock time, or what happens everytime a USB ISO packet is sent from the device to the host. This IS the ambiguity.
4. This is because the device can specify whether it is sending data every microframe, or every other uFrame, of every 4th uFrame etc.
5. Now when folks tested the OSX driver for uac2, and also the Win driver under uac1 BUT at HIGH speed, it is found that these drivers treat the rate feedback format as 16.16 per uFrame of data sent. (ie NOT absolute 125uS time).
6. So for devices that send every 2 uFrame (such as the AW), the rate feedback format becomes the number of samples per 0.250 ms, or number of samples >> 2 every 1 ms.
7. With this rate feedback format and value, we found that OSX and Windows uac2 drivers (and also uac1 driver running at HIGH speed) are all happy.
8. However, Linux implemented a 12.13 format in the old days (before kernel 2.6.37) and since then, an automatic rate format detection algorithm was implemented which will automatically adjust the feedback format recognized by comparing the norminal sampling rate with the feedback rate. If it is off by -25% or +50%, it is assumed to be a wrong frmat and the bits are shifted left or right a number of times to find a match.
9. This has worked well for the AW with the standard code that works under OSX and Wndows.
10. However, when folks like Demian started stress testing Linux and mpd, with playback of mixed sampling rate tracks in the same album, it revealed possible problems. We are still investigating the root cause of the problems, but it looks like this at the moment:
(a) When playing music at say 44.1khz, the nominal freq is 44.1khz and the rate feedback is within -25% and +50% of nominal freq. So all is well;
(b) Now under Linux, mpd and alsa uac2 driver, when suddenly the track goes from 44.1khz to 96khz (say), the nominal freq somehow is not changed, and the rate feedback changes to around 96khz. The alsa uac2 driver then assumes that the feedback format has changed (which has not) and you can see that it will cause severe problems.
(c) This does not occur under Windows or OSX as the rate feedback format is deemed to be fixed. Also , under Windows or OSX, with the music player software that we have tested, when a track is changed to the next one, and if the sampling rate has changed, the software and driver will change the norminal freq accordingly. So there is no problem.
(d) Playback software may not be "well behaved" and it can give problems to the uac2 driver. For example, changing tracks (with different sample rates) without informing the driver to issue the correct uac2 change sampling rate commands, or stopping playback stream suddenly without informing the driver to issue USB commands to change the ISOCHRONOUS alternate back to 0 to conserve USB bandwidth etc. How the uac2 driver should respond (eg, should there be a time out when no more data comes through from the player software so that the ISO pipe can be shut down? ).
Alex
OK. This is a very technical subject and is very confusing. But I will just give some pointers and you can do more research
1. In UAC2 specs, page 40, section 3.16.2.2, it says the feedback format to " refer to Section 5.12.4.2, “Feedback” and Section 9.6.6, “Endpoint” in the USB Specification.
2. In the USB2.0 specs, page 73, section 5.12.4.2, it basically says the format should be:
10.14 for full-speed device and 16.16 for high speed device.
For full speed device, it should be per frame (ie 1 msec). For high speed device, it should be per uFrame (ie per 125us).
3. HOWEVER, there is no mention of what this per microframe is referring to. Is this the absolute per every 125us realtime clock time, or what happens everytime a USB ISO packet is sent from the device to the host. This IS the ambiguity.
4. This is because the device can specify whether it is sending data every microframe, or every other uFrame, of every 4th uFrame etc.
5. Now when folks tested the OSX driver for uac2, and also the Win driver under uac1 BUT at HIGH speed, it is found that these drivers treat the rate feedback format as 16.16 per uFrame of data sent. (ie NOT absolute 125uS time).
6. So for devices that send every 2 uFrame (such as the AW), the rate feedback format becomes the number of samples per 0.250 ms, or number of samples >> 2 every 1 ms.
7. With this rate feedback format and value, we found that OSX and Windows uac2 drivers (and also uac1 driver running at HIGH speed) are all happy.
8. However, Linux implemented a 12.13 format in the old days (before kernel 2.6.37) and since then, an automatic rate format detection algorithm was implemented which will automatically adjust the feedback format recognized by comparing the norminal sampling rate with the feedback rate. If it is off by -25% or +50%, it is assumed to be a wrong frmat and the bits are shifted left or right a number of times to find a match.
9. This has worked well for the AW with the standard code that works under OSX and Wndows.
10. However, when folks like Demian started stress testing Linux and mpd, with playback of mixed sampling rate tracks in the same album, it revealed possible problems. We are still investigating the root cause of the problems, but it looks like this at the moment:
(a) When playing music at say 44.1khz, the nominal freq is 44.1khz and the rate feedback is within -25% and +50% of nominal freq. So all is well;
(b) Now under Linux, mpd and alsa uac2 driver, when suddenly the track goes from 44.1khz to 96khz (say), the nominal freq somehow is not changed, and the rate feedback changes to around 96khz. The alsa uac2 driver then assumes that the feedback format has changed (which has not) and you can see that it will cause severe problems.
(c) This does not occur under Windows or OSX as the rate feedback format is deemed to be fixed. Also , under Windows or OSX, with the music player software that we have tested, when a track is changed to the next one, and if the sampling rate has changed, the software and driver will change the norminal freq accordingly. So there is no problem.
(d) Playback software may not be "well behaved" and it can give problems to the uac2 driver. For example, changing tracks (with different sample rates) without informing the driver to issue the correct uac2 change sampling rate commands, or stopping playback stream suddenly without informing the driver to issue USB commands to change the ISOCHRONOUS alternate back to 0 to conserve USB bandwidth etc. How the uac2 driver should respond (eg, should there be a time out when no more data comes through from the player software so that the ISO pipe can be shut down? ).
Alex
Master class. It is difficult to understand completely, but gives a good idea of how USB post data in Windows, Linux and OSX.This is a very technical subject and is very confusing. But I will just give some pointers and you can do more research
AB-1.12 proto updates
Here's a little update I prepared on the plane last night. The answer to your question is at the very bottom...
Work on the AB-1.12 prototype board is progressing. I have noted your consern about regulator heat dissipation.
Recently I have added a CS8406 SPDIF transmitter. Please see the attached schematic and let me know if you have any opinions. Both sch and layout are mostly done. The transmitter runs from the same ADP151 LDO as the DAC usually gets its power from. The reason simply being that the DAC is likely to be of less importance with SPDIF output. The keen eye will discover an SPDIF output pin on the module interface. Take no alarm, this is merely for reserving a pin for such a signal should it occur later. (The CS8406 can act as a "smart" transmitter with I2S in, or as a driver only, in which case a CMOS buffer can probably do the same job.)
Also, I have set it up in Software mode with I2C. That means a bit of MCU programming is needed in order to make it work. There are also GPIO pins for a few controls which we will probably not need anyway. One of them is a (probably never used) interrupt generated at the CS8406. I have not yet checked if this maps to an interrupt on the MCU. A word of warning:
I will probably not have the time to do the programming job myself. Actually, I don't even own equipment with SPDIF in. (Although I do consider a Juli@ card.) So if you're keen on SPDIF output feel free to read up on the CS8406 and I2C for the AVR32.
The SPDIF header will be placed on the front, opposite the logo from the LED. At the moment I'm only reserving footprint space for an SPDIF output. But both differential AES/EBU and TOSLINK should be easy to patch in.
Cheers,
Børge
P.S. Like stated before, the AB-1.12 will be a naked board the size of the bottom board in the AB-1.1 kit. It will ship with two loose Golledge XOs and new front/back plates. You will need the box and module from an existing AB-1.1 for it to work. (There is no reason to postpone that AB-1.1 purchase until the availability of the AB-1.12 board It will feature an PCM5102 main DAC, SPDIF output, 3 free-floating Demian/Oneoclock regulators, and finally 2 free-floating ES9012/8 footprints for which you are on your own and must provide own power, IVC etc.
Here's a little update I prepared on the plane last night. The answer to your question is at the very bottom...
Work on the AB-1.12 prototype board is progressing. I have noted your consern about regulator heat dissipation.
Recently I have added a CS8406 SPDIF transmitter. Please see the attached schematic and let me know if you have any opinions. Both sch and layout are mostly done. The transmitter runs from the same ADP151 LDO as the DAC usually gets its power from. The reason simply being that the DAC is likely to be of less importance with SPDIF output. The keen eye will discover an SPDIF output pin on the module interface. Take no alarm, this is merely for reserving a pin for such a signal should it occur later. (The CS8406 can act as a "smart" transmitter with I2S in, or as a driver only, in which case a CMOS buffer can probably do the same job.)
Also, I have set it up in Software mode with I2C. That means a bit of MCU programming is needed in order to make it work. There are also GPIO pins for a few controls which we will probably not need anyway. One of them is a (probably never used) interrupt generated at the CS8406. I have not yet checked if this maps to an interrupt on the MCU. A word of warning:
I will probably not have the time to do the programming job myself. Actually, I don't even own equipment with SPDIF in. (Although I do consider a Juli@ card.) So if you're keen on SPDIF output feel free to read up on the CS8406 and I2C for the AVR32.
The SPDIF header will be placed on the front, opposite the logo from the LED. At the moment I'm only reserving footprint space for an SPDIF output. But both differential AES/EBU and TOSLINK should be easy to patch in.
Cheers,
Børge
P.S. Like stated before, the AB-1.12 will be a naked board the size of the bottom board in the AB-1.1 kit. It will ship with two loose Golledge XOs and new front/back plates. You will need the box and module from an existing AB-1.1 for it to work. (There is no reason to postpone that AB-1.1 purchase until the availability of the AB-1.12 board
It will feature an PCM5102 main DAC, SPDIF output, 3 free-floating Demian/Oneoclock regulators, and finally 2 free-floating ES9012/8 footprints for which you are on your own and must provide own power, IVC etc.
Last edited:
Hi,
a beaglebone would probably make a nice companion for the widget, especially with a serious distro aboard...
Rüdiger
a beaglebone would probably make a nice companion for the widget, especially with a serious distro aboard...
Rüdiger
I had a quick meeting with the AKM guys today. I was not asking but they suggested two digital transmitters, the AK4103 and the AK4104. The AK4103 has an on-board driver that can drive SPDIF/AES transformers directly. The AK4104 has a digital output and needs a driver or Toslink output only.
For the output function there should be very little difference if any between all the parts available since its a very well defined function and all digital. Setting all the special header bits is possible with the AKM parts in either static or programmed modes. Although it seems no one uses the sample rate info encoded in the header, probably because its often wrong.
If you want to be obsessive you could use the 4104 with a clocked latch on the output to resync to the clock edges removing any internal prop delays. I can think of much better ways to burn through time.
For the output function there should be very little difference if any between all the parts available since its a very well defined function and all digital. Setting all the special header bits is possible with the AKM parts in either static or programmed modes. Although it seems no one uses the sample rate info encoded in the header, probably because its often wrong.
If you want to be obsessive you could use the 4104 with a clocked latch on the output to resync to the clock edges removing any internal prop delays. I can think of much better ways to burn through time.
I just noticed that myself.
NuHorizons Nu Horizons Electronics - Electronic Components Distributor lists them but has 0 stock. My next call with AKM will be fun. . .
They are pretty cheap.
NuHorizons Nu Horizons Electronics - Electronic Components Distributor lists them but has 0 stock. My next call with AKM will be fun. . .
They are pretty cheap.
A nice piece of info for those who run Windows.
Over on the Audio-Widget list Nikolay has been working on an ASIO driver for the audio-widget (Borge's AB-1 and my USBxxxx series) I would like to let the DiyAudio world know we now have a fully open source DAC + driver for Windows.
I installed Nikolay's latest package and was able to run my USB5012 card on an Acer Netbook with Win7. I played 96k flac files using the latest foobar2000 and I will try and scrounge up a 24b/192k file later today.
The driver may need some polish but it is nice to have a fully open-source DAC, from schematic to driver. The DIY community is no longer tied to a manufacturer USB/UAC engine or limiting NDA's. Congratulations Nikolay.
George Boudreau
Yoyodyne Consulting
Over on the Audio-Widget list Nikolay has been working on an ASIO driver for the audio-widget (Borge's AB-1 and my USBxxxx series) I would like to let the DiyAudio world know we now have a fully open source DAC + driver for Windows.
I installed Nikolay's latest package and was able to run my USB5012 card on an Acer Netbook with Win7. I played 96k flac files using the latest foobar2000 and I will try and scrounge up a 24b/192k file later today.
The driver may need some polish but it is nice to have a fully open-source DAC, from schematic to driver. The DIY community is no longer tied to a manufacturer USB/UAC engine or limiting NDA's. Congratulations Nikolay.
George Boudreau
Yoyodyne Consulting
that's a step in the right direction.
however, what is the supply chain like, when its in stock?
is it steady? does their stuff take a long lead time to restock? do they keep models around for a while or EOL them quickly?
if akm is 'ok' in all these regards, that's cool. but I suspect they are not quite the 'digikey friendly' company that, say, ti or wolfson or cirrus is.
although personally I couldn't care less about windoze drivers,
I agree that this is a great news for the project. Which may bring lots of new people to it. Thanks and kudos to Nikolay! 
BTW: will this work also on XP?
although personally I couldn't care less about windoze drivers,
BTW: will this work also on XP?
I prefer Linux myself but it is hard to ignore that 'other' OS. I haven't tired it on my wife's computer yet but I will give it a go later today.
We use the AK5394A ADC for the sdr-widget project. It outperforms all other soundcards based on other chips, that we have tested, in terms of quiescent noise floor and dynamic range. It is especially evident at 192khz sampling.
I would hope that the AK DAC will have great performance as well.
Alex
I would hope that the AK DAC will have great performance as well.
Alex