I just installed the latest version (12-29-elf) and it mostly works fine. However I have found a way to trick it. If I start a track at a different sample rate that has music right at the beginning it seems to lock at a different sample rate or something. The tracks are very distorted.
This is using Linux/mpd/UAC2 and high sampe rate tracks mxed with standard sample rate tracks.
The easiest way to test this- There are sample tracks from Soundkeeper Recordings Format Comparison I was using the "dragon boats" pair and moving from the 44.1 to the 96 would cause the 96 to sound really wrong (broken). Reverse the order (96 then 44.1) and the problem is not present. Pause and play and it works fine. These tracks seem to have very little or no silence in front of them. Let me know if you need more info.
I may try this on Windows but that's a lot more work to get everything running.
This is using Linux/mpd/UAC2 and high sampe rate tracks mxed with standard sample rate tracks.
The easiest way to test this- There are sample tracks from Soundkeeper Recordings Format Comparison I was using the "dragon boats" pair and moving from the 44.1 to the 96 would cause the 96 to sound really wrong (broken). Reverse the order (96 then 44.1) and the problem is not present. Pause and play and it works fine. These tracks seem to have very little or no silence in front of them. Let me know if you need more info.
I may try this on Windows but that's a lot more work to get everything running.
Demian, perhaps ist's easier to check the same issue with a different DAC? My initial suspicion is the OS's way to mix and sample convert and stay async get in each other's ways. Does that description fit?
I'll try some varieties on Win7-32, but not being at my lab at the moment means I can only do limited diagnosis.
Børge
I'll try some varieties on Win7-32, but not being at my lab at the moment means I can only do limited diagnosis.
Børge
Normally Windows resamples everything to a single sample rate, and not with the best algorithm. There are a few players that will work around this, Foobar and JRiver are the first to come to mind. I tried VLC but got nowhere. JRiver supports ASIO. I managed to get the same problem in JRiver switching between a 44.1 and a 176 file. It seems to happen on the transition to a higher sample rate. At least is seems to be a specific repeatable problem.
Hi guys, you all seem to delight in findings ways to trick the audio-widget 
This latest observation is again from software that does not properly inform the driver that things have changed, and just switch the mode of sending audio samples.
In the earlier case, the app just stopped sending samples without doing a USB set alternate to.zero bandwidth. In this current case, I suspect the app just started to send 172.4 kHz samples without telling the driver that sample rate has changed !!! Poor audio-widget has to try frantically to rate feedback to the host to send LESS samples (as expected by the earlier 44.1khz rate) and fails :-(. Thus the distortion.
It is quite frustrating to have to continue to find workarounds for quirks in host software
Let me think about whether this sudden unannounced sample rate change can be worked around
In the meantime, my own workaround is not to mix mixed sample rate material in the same album - in fact I never do that.
Alex
This latest observation is again from software that does not properly inform the driver that things have changed, and just switch the mode of sending audio samples.
In the earlier case, the app just stopped sending samples without doing a USB set alternate to.zero bandwidth. In this current case, I suspect the app just started to send 172.4 kHz samples without telling the driver that sample rate has changed !!! Poor audio-widget has to try frantically to rate feedback to the host to send LESS samples (as expected by the earlier 44.1khz rate) and fails :-(. Thus the distortion.
It is quite frustrating to have to continue to find workarounds for quirks in host software
Let me think about whether this sudden unannounced sample rate change can be worked around
In the meantime, my own workaround is not to mix mixed sample rate material in the same album - in fact I never do that.
Alex
This, in a nutshell, is why a UAC2 Windows driver is a major undertaking.
The odd part is that the playback is stuck until the stream is paused. Possibly its the low to high rate shift. it doesn't seem to happen with high to low. It may also be related to the 2:1 or 4:1 ratios, so alternate samples are almost right? This is the same problem with two different OS's, Windows w/ UAC2 driver and Linux w/ ALSA UAC2 driver. I can get an XMOS based DAC and see if this happens with it under these circumstances. I know its extreme but its expected today. You are so close now.
The odd part is that the playback is stuck until the stream is paused. Possibly its the low to high rate shift. it doesn't seem to happen with high to low. It may also be related to the 2:1 or 4:1 ratios, so alternate samples are almost right? This is the same problem with two different OS's, Windows w/ UAC2 driver and Linux w/ ALSA UAC2 driver. I can get an XMOS based DAC and see if this happens with it under these circumstances. I know its extreme but its expected today. You are so close now.
Yes, I did a reboot. The installer claims it might be a path issue, but gives no info how and where to add which path variable.
you may try to build it from sources... or get rid of Gentoo and move to another distro.
BTW: why has pythoncard been dicarded? It's still in Debian, so I guess there should be no licence or maintenance/compatibility issues...
Here is a corresponding https://bugs.gentoo.org/show_bug.cgi?id=330683bugtracker info
I don't get the problem, though
Rüdiger
I know what you're talking about. Having developed USB firmware, I expect the same Alternate Interface (with zero bandwidth) should be selected at some point, and that's true whether the USB Device is Audio Class or even some other Isochronous link.
However, I do not recall seeing any rules in the USB Specifications that require an application or an operating system on a USB Host to set the Interface to Alternate 0 (the default one with zero bandwidth). Can anyone point to specific rules? If what we expect is not happening, then I'd like to know whether it is truly in violation of requirements, or just something 'nice' to do that is being skipped by lazy application developers.
Hi rsdio,
I don't know whether it is a specific requirement that is written somewhere. Will have to do some research when I'm free
ISOCHRONOUS reserves the bandwidth (and often quite a large chunk) and when the app wants to starting sending, it dutifully set alternate to 1 (or whichever alternative interface number to be used) before sending data. I would expect a well behaved app to set alternate back to 0 after finishing the sending of data instead of hogging the bandwidth
Anyway it is a moot point as UnixMan has demonstrated that he can trick the app as well, by manually pausing the application half way through a unix signal to the app and the app doesn't (have time to) do any cleanup before stopping. And an app can hang halfway too from bugs.
The unannounced stop sending data issue has been fixed more or less by the watch dog process.
My present thinking is that I should enhance the watch dog by monitoring the approximate incoming USB data rate and compute the likely audio sample rate that the host is sending. When a sudden change is detected, the watch dog will switch the audio-widget sampling rate to match. (This is a big jump switch, as in changing from 44.1 to 176.4 etc., instead of the minute rate feedback throttle changes.)
Alternatively, I can take a look at mpd source code and fix mpd (But it will not help Windows users.)
Alex
I don't know whether it is a specific requirement that is written somewhere. Will have to do some research when I'm free
ISOCHRONOUS reserves the bandwidth (and often quite a large chunk) and when the app wants to starting sending, it dutifully set alternate to 1 (or whichever alternative interface number to be used) before sending data. I would expect a well behaved app to set alternate back to 0 after finishing the sending of data instead of hogging the bandwidth
Anyway it is a moot point as UnixMan has demonstrated that he can trick the app as well, by manually pausing the application half way through a unix signal to the app and the app doesn't (have time to) do any cleanup before stopping. And an app can hang halfway too from bugs.
The unannounced stop sending data issue has been fixed more or less by the watch dog process.
My present thinking is that I should enhance the watch dog by monitoring the approximate incoming USB data rate and compute the likely audio sample rate that the host is sending. When a sudden change is detected, the watch dog will switch the audio-widget sampling rate to match. (This is a big jump switch, as in changing from 44.1 to 176.4 etc., instead of the minute rate feedback throttle changes.)
Alternatively, I can take a look at mpd source code and fix mpd
(But it will not help Windows users.)Alex
Exactly. This stems from the requirement that the 'default' Interface must have 0-byte packet sizes for all isochronous endpoints (or no iso endpoints at all). Thus, no bandwidth is allocated for a Device just because it is plugged in to the USB connector. Only when an application requests the alternate interface does the USB Host allocate bandwidth (or deny the change if insufficient bandwidth is available).
As a side note, this is distinctly different from how Bulk bandwidth is handled, in that there is never a guarantee for Bulk bandwidth - only the ability to utilize the leftover bandwidth so long as it is available.
Unix and similar operating systems have the ability to free application resources when a process is destroyed, even if the application does not manually free these resources. What I am curious about is whether a system like Mac OS X treats USB state as a resource to be corrected when an application is killed or otherwise dies. Since the isochronous bandwidth is so well defined, even for non-Audio Class Devices, it at least seems feasible for the operating system to handle setting things back to normal. Maybe I'll ask on the Apple USB Mailing List about whether this is something they do, and/or whether they think it would be a good idea to implement if they haven't already.I would expect a well behaved app to set alternate back to 0 after finishing the sending of data instead of hogging the bandwidth
Well, at least my software is written to hook all Unix signals so that the proper thing happens. It's at least possible to write a program that would respond to the Unix signal correctly. Then again, I think it might be reasonable for a software developer to expect that no normal user would ever use Unix signals to pause their audio, and thus they might simply response by saying that their application does not support Unix signaling at all.
If I were to implement a software player, I would continue a steady stream of audio samples during pause, but they would ramp to zero (silence) smoothly. Then, when Pause mode is terminated, the audio buffers would ramp back up from silence until the full audio is resumed. Under no circumstances would I expect to write an application which could continue to provide appropriate audio samples which the process is completely paused, because I believe that technically means that the process gets no CPU, doesn't it?
Standalone usage of USB CPU board
Is it possible to use the USB CPU board in standalone mode?
Can I connect it to the USB and will it work ?
What I see is that the power supply regulation is on board, and there's also a 12 Mhz clock. Of course the board will do nothing in this way, but can be a start to connect a different DAC ...
Is it possible to use the USB CPU board in standalone mode?
Can I connect it to the USB and will it work ?
What I see is that the power supply regulation is on board, and there's also a 12 Mhz clock. Of course the board will do nothing in this way, but can be a start to connect a different DAC ...
Just received my Audio Widget USB DAC - MANY thanks for the fast postage Børge - much appreciated indeed!
Looking forward to connecting it up to my 2009 Mac mini shortly, and trying it out with some high-res files via Audirvana & also Bitperfect for iTunes
I won't be able to help out on the coding side alas, but I'll definitely look into the PSU and the analogue outputs once I've gotten a handle on its sound quality as it is now.
- John
Looking forward to connecting it up to my 2009 Mac mini shortly, and trying it out with some high-res files via Audirvana & also Bitperfect for iTunes
I won't be able to help out on the coding side alas, but I'll definitely look into the PSU and the analogue outputs once I've gotten a handle on its sound quality as it is now.
- John
Yes, you can use the board stand-alone. But you need to patch VBUS out to +5V in. The code will be a little confused when it isn't receiving any audio MCLK. I can't really tell you how much will work.
For use with another DAC you will need to provide both clocks (or change enumeration for the one you do provide) at 44.1*256 / 48*256.
Børge
For use with another DAC you will need to provide both clocks (or change enumeration for the one you do provide) at 44.1*256 / 48*256.
Børge
sorry, don't know where to set it in windows.
Try google. looks like a problem with older versions, though. In Debian Wheezy I have Python 2.7, wx* 2.8 and pythoncard 0.8.
Installation of the widget went 100% smoothly with the Mac mini (running Lion OS). Just had to select it in the sound preferences window, plus the Audio/MIDI setup screen, and Bitperfect (audio playback software which allows one to use iTunes but with a much better/purer audio engine).
Works very smoothly indeed with all sample rates I could throw at it. No glitches, except occasionally a small burst of noise when going from one sample rate to another (i.e. playback on random, so a selection of differing sample rates).
The most pleasant surprise has been the sound quality (which hardly anyone seems to mention here...!) - I have to say for the price I wasn't expecting anything too fantastic at all, but it's seriously really REALLY good indeed! Terrific detail, a thunderous bass (when called for). Clean and very clear. Great lightning quick dynamics. Very neutral indeed, without being bland. You could easily stick this into a fancy CNC machined chassis and charge £1000! I look forward to seeing if I can squeeze any extra performance out of it by building an external PSU when I get around to it.
My only minor gripe was when I tried to use it with Windows7 it wasn't recognised, and installing the driver didn't seem to help either. I obviously need to take a very close look at the various setup guides for Windows use. However as I'll be using the Mac most of the time it's absolutely a joy to setup.
Very nice work indeed guys - this wins my personal favourite audio product of the year award !
- John
Works very smoothly indeed with all sample rates I could throw at it. No glitches, except occasionally a small burst of noise when going from one sample rate to another (i.e. playback on random, so a selection of differing sample rates).
The most pleasant surprise has been the sound quality (which hardly anyone seems to mention here...!) - I have to say for the price I wasn't expecting anything too fantastic at all, but it's seriously really REALLY good indeed! Terrific detail, a thunderous bass (when called for). Clean and very clear. Great lightning quick dynamics. Very neutral indeed, without being bland. You could easily stick this into a fancy CNC machined chassis and charge £1000! I look forward to seeing if I can squeeze any extra performance out of it by building an external PSU when I get around to it.
My only minor gripe was when I tried to use it with Windows7 it wasn't recognised, and installing the driver didn't seem to help either. I obviously need to take a very close look at the various setup guides for Windows use. However as I'll be using the Mac most of the time it's absolutely a joy to setup.
Very nice work indeed guys - this wins my personal favourite audio product of the year award
! - John
Last edited:
El.Cap., again. Quick question. I've seen that there are Elna Silmic II @6.3V which may even fit in the proper places on the AB1.1 PCB (IIRC for values up to 220uF). Prices are also quite acceptable:
Elna Electrolytic Capacitors RFS Series
is there any reason why not to use them? Otherwise, I'm gonna try some... perhaps up to 1000uF, somewhere.
Elna Electrolytic Capacitors RFS Series
is there any reason why not to use them? Otherwise, I'm gonna try some... perhaps up to 1000uF, somewhere.
Thanks John for the nice report. Indeed you will get the best SQ playing the audio-widget under OSX or Linux as uac2 is natively supported and is accorded the appropriate (ie very high) CPU and interrupt priorities.
We have tested experimental uac2 drivers under Windows and SQ is better than uac1 when playing high sample material. However, somehow the SQ is dependent on which player software we used and is just not as good as Linux playback using mpd (with auto resampling turned off). Remember that without uac2 driver (3rd party. We don't have any), u must set audio-widget to uac1_audio. Otherwise it will blue screen WinXP and not work under W7.
Wei, Demian and others have posted their analog mods. You might like to read them and then decide on your own mod. Let us know how they influence the SQ
Alex
We have tested experimental uac2 drivers under Windows and SQ is better than uac1 when playing high sample material. However, somehow the SQ is dependent on which player software we used and is just not as good as Linux playback using mpd (with auto resampling turned off). Remember that without uac2 driver (3rd party. We don't have any), u must set audio-widget to uac1_audio. Otherwise it will blue screen WinXP and not work under W7.
Wei, Demian and others have posted their analog mods. You might like to read them and then decide on your own mod. Let us know how they influence the SQ
Alex
Go nuts! And tell us how it influences the sound.
Børge
Børge
El.Cap., again. Quick question. I've seen that there are Elna Silmic II @6.3V which may even fit in the proper places on the AB1.1 PCB (IIRC for values up to 220uF). Prices are also quite acceptable:
Elna Electrolytic Capacitors RFS Series
is there any reason why not to use them? Otherwise, I'm gonna try some... perhaps up to 1000uF, somewhere.