Resuming the situation in Windows XP 32
I've tried to follow all the posts, and the other information on cited links ... but I'm getting lost
!
Can somebody please resume the sitaution about using Audio Widget with Windows XP 32 bit? Is UAC2 experimental driver available for some testing?
I'm a long time professional windows programmer ... maybe I can be interested in developing or helping develop the infamous UAC2 driver ... but first can somebody please resume the situation about its development? Forums are interesting, but information is often too "diluted" in long posts and it's difficult to make the point.
Thank you all.
I've tried to follow all the posts, and the other information on cited links ... but I'm getting lost
!Can somebody please resume the sitaution about using Audio Widget with Windows XP 32 bit? Is UAC2 experimental driver available for some testing?
I'm a long time professional windows programmer ... maybe I can be interested in developing or helping develop the infamous UAC2 driver ... but first can somebody please resume the situation about its development? Forums are interesting, but information is often too "diluted" in long posts and it's difficult to make the point.
Thank you all.
The only problem of Voyage MPD is that it requires a LAN with a DHCP server and at least another host to run the client. Nowadays that's pretty common, yet not everyone have such setup available (and close enough to the audio system).
If we want to prepare something ready to try for anyone, it should have some easy to use (TUI?) MPD client preinstalled, so that one may try it also without another machine and network connection.
I'd also add at least sox with plugins, etc, so that one may also simply do something like
cd /some/music/dir
play *.flac
There are sooo many mpd clients. I would look at adding a CLI client or something like ncmpc. This, content on a USB stick (needs three USB ports now) and a monitor and keyboard and you are running.
What I would recommend here is that someone build a Voyage MPD install on a USB stick, setup mpd.conf to talk to USB. Perhaps a little script to check the system and list possible mpd outputs since they seem to move on different boxes.
The SOX idea is good but even more geeky.
Adding a window manager and a graphic client like GMPC would be a more major undertaking.
There is also a touchscreen client I tried to get running pymptouchgui Client
ympdtouchgui - Music Player Daemon Community Wiki but it was proving to be more than I was ready to deal with then.Once built it can be backed up to a compressed file and written to a USB stick with Selfimage. Share it with Rapidshare or bittirrent.
I would do it but I have CES grinding down on me. Maybe after CES.
I've tried to follow all the posts, and the other information on cited links ... but I'm getting lost
Can somebody please resume the sitaution about using Audio Widget with Windows XP 32 bit? Is UAC2 experimental driver available for some testing?
I'm a long time professional windows programmer ... maybe I can be interested in developing or helping develop the infamous UAC2 driver ... but first can somebody please resume the situation about its development? Forums are interesting, but information is often too "diluted" in long posts and it's difficult to make the point.
Thank you all.
The only UAC2 drivers for Windows are proprietary and targeted at specific hardware. You might well be able to hack one to talk to different hardware to work for you but you would need to write something from scratch to publish it. The Linux driver works well but I doubt that it would be very useful for Windows since the framework is so different. And XP, Win7+ Vista, Win7 64 are enough different that you really are talking about three different drivers. Its a major undertaking I believe.
The bulk of USB audio devices with the higher sample rates (Creative, MAudio etc.) all use non UAC2 interfaces. There are a flood of UAC2 chips on the way from CMedia, Tenor, Via etc. and the pressure for drivers will ratchet up. Most of those may end up with buggy drivers hastily created just to sell chips or cheap boxes.
If an open source Win UAC2 driver were published I'm sure there would be a lot of interest and support.
As Damien pointed out, you need to write an open source windows uac2 driver from scratch, and you need to cater to the specifics of different Windows (XP, Vista, W7) and 32 vs 64 bits etc.
You don't have access to the source codes of the commercially available drivers so it will not help, let alone the IP issue.
It has been said that it takes about 1 man-year to write the driver so to have any reasonable chance of success it has to be a team effort.
Alex
You don't have access to the source codes of the commercially available drivers so it will not help, let alone the IP issue.
It has been said that it takes about 1 man-year to write the driver so to have any reasonable chance of success it has to be a team effort.
Alex
no.
you can use it out of the box (no driver required) in UAC1 (async) mode, which works perfectly and sounds as good as UAC2, but is limited to max 24/48.
something like "ncmpc" (a "TUI") is exactly what I had in mind.
actually, you may add whatever you like in almost no time. Voyage is basically just a Debian stable (currently Squeeze) with some extra repositories (for a different kernel, updated alsa, etc) and some customization. Installing a complete desktop environment is just an "apt-get install <whatever>" away.
OTOH, installing X and a GUI would completely change the very "nature" and ideas behind Voyage.
what about creating an ASIO driver? by-passing all of the windoze audio stack, there should be much less differences between the various windoze versions... and in most cases it will also sound better.
ASIO is supported by the best audio software. And by some of the most common, like e.g. Foobar, too.
Who cares about WMP...
Last edited:
Windows driver
Here is an overdue response to an older post.
Audiodesign, I assume you're referring to the WDK. I'm downloading it from Download: WDK 7.1.0 - Microsoft Download Center - Download Details and plan to play around with it.
I'm not familiar with USB programming, but here are a couple more or less intelligent suggestions. Can we for example:
- Recompile the windows UAC1 driver for our DAC enumerating as something else than generic UAC1 (which is already in the OS)
- Introduce one feature at the time in the driver and firmware, slowly approaching the running UAC2 code
- If we can't write wrappers for it, can we at least use the ALSA code as a todo list or code spec
Børge
Here is an overdue response to an older post.
Audiodesign, I assume you're referring to the WDK. I'm downloading it from Download: WDK 7.1.0 - Microsoft Download Center - Download Details and plan to play around with it.
I'm not familiar with USB programming, but here are a couple more or less intelligent suggestions. Can we for example:
- Recompile the windows UAC1 driver for our DAC enumerating as something else than generic UAC1 (which is already in the OS)
- Introduce one feature at the time in the driver and firmware, slowly approaching the running UAC2 code
- If we can't write wrappers for it, can we at least use the ALSA code as a todo list or code spec
Børge
I'd like to know if UAC2 (as implemented in the Audio Widget) can be both isochronous and asynchronous ... sorry if it's a stupid question, but it's related to sound quality.
I'm actually making some test using UAC2 , and the sound quality is not top notch as I would expect from the hardware (double high quality clock) and asynchronous implementation. I did my tests in Windows (XP), but as I get no problems and a "probe" utility that I have says that everything is OK, so I guess that under linux it would be the same ... are we really going Asynchronous?
As regards the UAC2 windows driver ... well, 1 man year is a lot of work, but I think that the task that has to be implemented is not so complex, so maybe it's rather over extimated ... after all what you have to do is just copy the data in blocks towards the USB ...
I'm actually making some test using UAC2 , and the sound quality is not top notch as I would expect from the hardware (double high quality clock) and asynchronous implementation. I did my tests in Windows (XP
), but as I get no problems and a "probe" utility that I have says that everything is OK, so I guess that under linux it would be the same ... are we really going Asynchronous?As regards the UAC2 windows driver ... well, 1 man year is a lot of work, but I think that the task that has to be implemented is not so complex, so maybe it's rather over extimated ... after all what you have to do is just copy the data in blocks towards the USB ...
The UAC spec is both isochronous and async. Really confusing. I believe what that means is that the audio is a stream that the interface modulates the rate of to keep in sync with the clock in the USB end point. The other approach used (by Hiface etc.) is to use bulk mode passing a block of data and waiting for the next request for data when the device buffer is nearly empty.
There is no fundamental reason why one should be better than the other. However the industry preferred spec it seems and the one supported by the drives on OSX and Linux is the isochronous one.
When you say the sound quality is not "top notch" can you be more specific. Parts and specs are not necessarily an indication of system performance. I think the ESS dac in the AB1 is the weakest part. It has a good reputation, for example in the Nuforce mini dac. However there are other better sounding parts. However those require some aspects that are missing and hard to create like a negative supply. The ESS dac is one of the best solutions with an onboard charge pump.
There is no fundamental reason why one should be better than the other. However the industry preferred spec it seems and the one supported by the drives on OSX and Linux is the isochronous one.
When you say the sound quality is not "top notch" can you be more specific. Parts and specs are not necessarily an indication of system performance. I think the ESS dac in the AB1 is the weakest part. It has a good reputation, for example in the Nuforce mini dac. However there are other better sounding parts. However those require some aspects that are missing and hard to create like a negative supply. The ESS dac is one of the best solutions with an onboard charge pump.
You may want to download this signal generator: Realtime Signal Generator for windows
Both UAC1 and UAC2 are asynchronous by firmware design. One interesting test would be to replace an XO with a good tuneable square wave generator. The pitch of a test tone should then vary as much as the frequency of the generator. Unfortunately, my square wave generator hardly qualified as door stopper, so I couldn't perform this test.
Michael, could you please fill in?
The generator will at least show you the DAC's response to some standard wave forms. One thing you'll see is that the ES9023 oversampling filter goes into nasty saturation if you play a square wave at >-1.5dB. (If I remember the number correctly.) Gibb's phenomenon is interesting on it self. Their OS doesn't simply clip as the output passes full-scale, it wraps around. As in 0xFE+0x03 = 0x01, not 0xFF.
Børge
Both UAC1 and UAC2 are asynchronous by firmware design. One interesting test would be to replace an XO with a good tuneable square wave generator. The pitch of a test tone should then vary as much as the frequency of the generator. Unfortunately, my square wave generator hardly qualified as door stopper, so I couldn't perform this test.
Michael, could you please fill in?
The generator will at least show you the DAC's response to some standard wave forms. One thing you'll see is that the ES9023 oversampling filter goes into nasty saturation if you play a square wave at >-1.5dB. (If I remember the number correctly.) Gibb's phenomenon is interesting on it self. Their OS doesn't simply clip as the output passes full-scale, it wraps around. As in 0xFE+0x03 = 0x01, not 0xFF.
Børge
Yes, it is confusing. But your interpretation of things match mine. Host is data-master and device is clock-master. I guess audio protocols traditionally focus on constant latency, and that copatibility issues matter. (Ref. black/white TVs being able to make sense out of color TV signals etc.)
Not being a USB programer of much merit, I have shown UAC2 specs to a couple guys who work professionally with USB programming. They say the task is huge.
However, the ALSA code is there, and implementing the same UAC2 (sub)set would get the job done, as far as I'm conserned. It would probably be easier in a Windows environment to use a different protocol, but we shouldn't have to switch firmware depending on the OS.
Børge
Not being a USB programer of much merit, I have shown UAC2 specs to a couple guys who work professionally with USB programming. They say the task is huge.
However, the ALSA code is there, and implementing the same UAC2 (sub)set would get the job done, as far as I'm conserned. It would probably be easier in a Windows environment to use a different protocol, but we shouldn't have to switch firmware depending on the OS.
Børge
First another request: can somebody point me to the source code of the firmware as implemented in the Audio Widget (I got mine from Borge just yesterday, the board says 20110716)? I cannot access GIT repositories ...
Then regarding Asynchrounous and UAC2 .... Let's put things in perspective.
All the recent rumours about USB audio quality is about the implementation of the hardware in a way that the board itself asks for the data, and has on board clocks .. contrasted to , say, simple chips like PCM2906 where the only needed clock is 12 Mhz (required by USB), the "dances" are led by the PC (with all related problems of stability and possible gaps), and the chip itself actually tries to synthetize the required output clock .
The best approach is that the audio board leads: the clocks are on board, the "pace" of data is strictly controlled, and the data is requested by the board to the PC and not vice versa. I assumed that the Audio Widget was implemented this way ... at least with UAC2. Am I wrong?
Regarding audio quality ... I'm saying that it's not "top notch" because I have the impression that there's something wrong or misconfigured. I get some edgy highs, I also tried the output caps ...
Now not that the music is horrible, but in my actual setup it's outperformed by a small cheap board (about 25 Euro including shipping) based on Tenor TE7022L USB controller and Wolfson 8761 chip (which is a cheap one too) ... this little board that I got from China is far more "musical", has a far better pace ....
The point is that in my opinion the Audio Widget, given its hardware, can do even better ... only that I miss something, or my setup is not correct, or the board actually works in isochronous mode (and so with less quality). That's why I'd like to take a look at the code. Moreover it's the first step to understand what is needed in the windows driver ...
Then regarding Asynchrounous and UAC2 .... Let's put things in perspective.
All the recent rumours about USB audio quality is about the implementation of the hardware in a way that the board itself asks for the data, and has on board clocks .. contrasted to , say, simple chips like PCM2906 where the only needed clock is 12 Mhz (required by USB), the "dances" are led by the PC (with all related problems of stability and possible gaps), and the chip itself actually tries to synthetize the required output clock .
The best approach is that the audio board leads: the clocks are on board, the "pace" of data is strictly controlled, and the data is requested by the board to the PC and not vice versa. I assumed that the Audio Widget was implemented this way ... at least with UAC2. Am I wrong?
Regarding audio quality ... I'm saying that it's not "top notch" because I have the impression that there's something wrong or misconfigured. I get some edgy highs, I also tried the output caps ...
Now not that the music is horrible, but in my actual setup it's outperformed by a small cheap board (about 25 Euro including shipping) based on Tenor TE7022L USB controller and Wolfson 8761 chip (which is a cheap one too) ... this little board that I got from China is far more "musical", has a far better pace ....
The point is that in my opinion the Audio Widget, given its hardware, can do even better ... only that I miss something, or my setup is not correct, or the board actually works in isochronous mode (and so with less quality). That's why I'd like to take a look at the code. Moreover it's the first step to understand what is needed in the windows driver ...
The Wiki is a good place to start. Getting started with git can be fascinating. The Wiki has an article on git access which may benefit from some editing, but at least the required info is there. Wiki Pages - sdr-widget - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
Are you talking about percieved musical fidelity or easily observed things like distortion? You may want to use the generator and see if any supply lines carry a correlated signal.
Børge
Are you talking about percieved musical fidelity or easily observed things like distortion? You may want to use the generator and see if any supply lines carry a correlated signal.
Børge
Hi Borge,
I'm talking about what seems distortion at high frequencies, which is probably connected to jitter.
As regards what I'm talking about, I would like to know if in the Audio Widget code “asynchronous” USB data transmission has been implemented.
The “asynchronous” part of the name means that the master audio clock in the D/A converter box need not be synchronized
with any of the clocks in the computer. This is breakthrough that allows for the jitter of an external D/A converter box to be as low as a one-box disc player.
With the “asynchronous” mode, the master audio clock is in the D/A converter box, where it belongs. A buffer in the D/A converter box stores the incoming audio data from the computer and the controller chip tells the computer to send more audio data as the buffer empties during playback.
I supposed this what implemented in the board firmware. All the hardware is threre, and this mode is part of the USB specification, so no special driver is needed.
I'll try to get to the code and see ...
I'm talking about what seems distortion at high frequencies, which is probably connected to jitter.
As regards what I'm talking about, I would like to know if in the Audio Widget code “asynchronous” USB data transmission has been implemented.
The “asynchronous” part of the name means that the master audio clock in the D/A converter box need not be synchronized
with any of the clocks in the computer. This is breakthrough that allows for the jitter of an external D/A converter box to be as low as a one-box disc player.
With the “asynchronous” mode, the master audio clock is in the D/A converter box, where it belongs. A buffer in the D/A converter box stores the incoming audio data from the computer and the controller chip tells the computer to send more audio data as the buffer empties during playback.
I supposed this what implemented in the board firmware. All the hardware is threre, and this mode is part of the USB specification, so no special driver is needed.
I'll try to get to the code and see ...
The isochronous part is the low-level USB data transfer, and all UAC data passed must be isochronous. Within that specification, there are three methods available, of which asynchronous is one option. So, at a slightly higher level, the audio content is moving asynchronously over a low-level isochronous transport. Because of the rate feedback, this all works without a conflict despite the seeming contradiction in terms.
Well, all you have to do is copy the data in blocks, but you must also adjust the size of the blocks according to the rate feedback and you must get the timing absolutely correct to avoid glitches. Writing software to move constant sized blocks where timing is not critical would certainly be easy, but once you add in the variable sizing and the precise timing requirements you have a much more challenging task.
The problem is that there is a fundamental change in the way things work when you switch from Full Speed Isochronous (limited to 1024 bytes per frame) to High Speed Isochronous (limited to 3 KB per (micro)frame, or something like that). In other words, you're using a new feature of USB 2, so modifying a USB 1 driver is not going to work unless you understand how to take advantage of the new features. I have not programmed for Windows, so I do not know how the API has changed. It may be the case that Windows handles all of the heavy lifting for you, and just might hide the details of the new features. But, basically, moving beyond the 24/48 limit of Full Speed UAC1 is not trivial because it requires a different approach. The technical differences between Full Speed and High Speed are what allow UAC2 to handle more channels and higher rates than UAC1, you can't simply run the old code faster (unless the OS makes the changes transparent to the programmer).
There is one fundamental reason why Isochronous is better than Bulk, and it happens to be the reason why the entire USB Audio Class (UAC) is specified as Isochronous only. Bulk transfer bandwidth is not guaranteed at all. It's entirely possible that the OS or bus could postpone Bulk transfers for an arbitrary amount of time. Proponents of Bulk audio argue that it is highly unlikely that the meager bandwidth of even 24/384 multichannel surround would ever starve, but the fact is that the lack of a guarantee at the OS level is a very important consideration. Under both UAC specifications, the device describes its maximum bandwidth needs, even under the worst clock rate feedback conditions, and the OS makes a guarantee that if your device is activated then it will guarantee bandwidth. If any bandwidth shortages occur, Bulk transfers will be postponed until the Isochronous transfers are fulfilled.
If you like glitch-free audio, guaranteed, then Isochronous is the only choice. You might be able to operate without glitches when using Bulk, but there is no guarantee that someone might plug the same hardware into a different USB 2 hub shared with other High Speed devices where glitches might suddenly occur for a few users. Isochronous takes the guesswork out of the equation by making the OS provide guarantees. There might be some minor aspects where Bulk had advantages over Isochronous, but I believe all of those were addressed with USB 2 High Speed improvements to Isochronous capabilities.
Another way to look at it is that no standard Audio driver will support Bulk, so you're forced to use a custom driver for each device with Bulk audio. You might think that's a small consideration, but I assume that eventually Windows will support UAC2 for driverless operations, and that's a great feature for users.
Hi Borge, all,
I did a quick test with AB-1.1 set to "uac2_audio" and stock firmware, supplying an external synthesizer clock.
With a 440Hz test signal generated by sox -r 88200 I get the following output:
21.5792 MHz -> 420.5 Hz
22.5792 MHz -> 440 Hz
23.5792 MHz -> 459.5 Hz
Now, does this qualify as asynchronous?
Hope that helps ... Michael
Hi Starn02,
I suspect you might not be getting the "top notch" SQ from the audio-widget because if PC software/settings.
Suggest you try;
1. Borrow a friend's Mac running OSX Snow Leopard or later
2. Borrow a Linux PC and run mpd and am mpd client with my previously posted .modconf configuration settings.
3. If u must continue with Windows only, try with PurePlayer. Do whatever optimization you can such as giving PurePlayer "real time" priority and stopping all non essential processes.
The audio-widget is running USB2 ( ie HIGH speed even in uac1 mode) so the demand in the PC CPU and USB resources are great compared to USB1.1 devices. So you really need to optimize your Windows for good sound. I have found that the best I could do under Win is still not as good as running under Linux. Under Windows PurePlayer it is very good, but for the "top notch" go for Linux or OSX.
Another consideration is the source music material. Try some native (ie not upsampled) 96/88.2/192 24bit music.
Another diagnostic clue is to watch the audio-widget Led's. When it is first started, the Led's flash to indicate rare feedback throttle changes. Then it should stabilize and either stop flashing or flashes once every 10-30 sec, indicating reaching optimal feedback rate.
Alex
I suspect you might not be getting the "top notch" SQ from the audio-widget because if PC software/settings.
Suggest you try;
1. Borrow a friend's Mac running OSX Snow Leopard or later
2. Borrow a Linux PC and run mpd and am mpd client with my previously posted .modconf configuration settings.
3. If u must continue with Windows only, try with PurePlayer. Do whatever optimization you can such as giving PurePlayer "real time" priority and stopping all non essential processes.
The audio-widget is running USB2 ( ie HIGH speed even in uac1 mode) so the demand in the PC CPU and USB resources are great compared to USB1.1 devices. So you really need to optimize your Windows for good sound. I have found that the best I could do under Win is still not as good as running under Linux. Under Windows PurePlayer it is very good, but for the "top notch" go for Linux or OSX.
Another consideration is the source music material. Try some native (ie not upsampled) 96/88.2/192 24bit music.
Another diagnostic clue is to watch the audio-widget Led's. When it is first started, the Led's flash to indicate rare feedback throttle changes. Then it should stabilize and either stop flashing or flashes once every 10-30 sec, indicating reaching optimal feedback rate.
Alex