<slightly OT rant>
Anyone half serious about 'Green computing' would favour ARM-based Linux would they not? The attraction of x86 as regards 'Green-ness' extends to the chance to get reasonable performance out of legacy platforms I'd have thought, rather than putting them in landfill. They'll still be very un-Green as regards energy usage all the same.
<normal service resumed
>
Anyone half serious about 'Green computing' would favour ARM-based Linux would they not? The attraction of x86 as regards 'Green-ness' extends to the chance to get reasonable performance out of legacy platforms I'd have thought, rather than putting them in landfill. They'll still be very un-Green as regards energy usage all the same.
<normal service resumed
>
Hi,
1. I'm currently checking out Voyage MPD. As with any Kernel matching or newer than around 2.6.39, the AB is online and working immediatly when plugged in. Very convenient. This is with those 'auto'-kernels. If you build your own kernel, include the usb-drivers appropriate to your hardware and be sure to include SND_USB_AUDIO. Done.
2. I made a quick check with streaming between to PC's with mpd/httpd. Works cool, and a - not so thorough - soundcheck did not reveal anything nasty.
Let the mpd music dir point to an NFS-directory on the lan is faster and invisible, so I consider this as being better.
Rüdiger
1. I'm currently checking out Voyage MPD. As with any Kernel matching or newer than around 2.6.39, the AB is online and working immediatly when plugged in. Very convenient. This is with those 'auto'-kernels. If you build your own kernel, include the usb-drivers appropriate to your hardware and be sure to include SND_USB_AUDIO. Done.
2. I made a quick check with streaming between to PC's with mpd/httpd. Works cool, and a - not so thorough - soundcheck did not reveal anything nasty.
Let the mpd music dir point to an NFS-directory on the lan is faster and invisible, so I consider this as being better.
Rüdiger
Hi Rüdiger,
it's cool that the hardware works out of the box. But how easy is this for someone with minimal Linux experience?
It would be great with a distro which could boot form CD/flash and straight into a music player, scan the local drives for music, save a minimal config file on existing fs. All with minimal interaction and kind looking graphics.
We have come far enough these days that installing a modern Linux variant is easier than installing Windows, so there is no reason the user should have to mess around in order to get an OS+driver+player combo up and running.
When you stream from the PC, are you sending music data from a Windows environment?
Børge
it's cool that the hardware works out of the box. But how easy is this for someone with minimal Linux experience?
It would be great with a distro which could boot form CD/flash and straight into a music player, scan the local drives for music, save a minimal config file on existing fs. All with minimal interaction and kind looking graphics.
We have come far enough these days that installing a modern Linux variant is easier than installing Windows, so there is no reason the user should have to mess around in order to get an OS+driver+player combo up and running.
When you stream from the PC, are you sending music data from a Windows environment?
Børge
Hi Børge,
I installed voyage on an old bureau-PC. They have a deal with a hardware company with low-energy ALIX-thin client they sell pre-configured, I understood.
The install procedure is a bit misty, I would not dare as a complete noob to try it.
But concerning AB1.1, it will work out of the box with any platform that has usb!
My music data is stored on a linux-server. MPD gets it via NFS. Easy, fast and reliable.
Rüdiger
I installed voyage on an old bureau-PC. They have a deal with a hardware company with low-energy ALIX-thin client they sell pre-configured, I understood.
The install procedure is a bit misty, I would not dare as a complete noob to try it.
But concerning AB1.1, it will work out of the box with any platform that has usb!
My music data is stored on a linux-server. MPD gets it via NFS. Easy, fast and reliable.
Rüdiger
Please forgive my question if the answer is obvious, but to me it isn't:
In this blog entry on setting up an audio PC the author mentions an expensive PCI-USB adapter card with dedicated power and whatnot. Is such a thing necessary with the asynchronicity of the AW, if clean external power is supplied to the analogue stage?
ElEsido
In this blog entry on setting up an audio PC the author mentions an expensive PCI-USB adapter card with dedicated power and whatnot. Is such a thing necessary with the asynchronicity of the AW, if clean external power is supplied to the analogue stage?
ElEsido
No, it should work from any decent USB port. The Analog Board of AB-1.1 is made to have all its power supplies ripped out and replaced by something which is cooler than VBUS+LDO.
Børge
Børge
Hi Rsdio,
I'm responding to post 624 with a new schematic. Does this USB circuit make more sense to you?
Børge
I'm responding to post 624 with a new schematic. Does this USB circuit make more sense to you?
Børge
Alternate Flash Linux option
This may be a better option for those who don't want to get close and personal with the Linux command line:Puppy Linux Discussion Forum :: View topic - mpdPup - Simplified MPD Music Server/Jukebox - New Version!
I like Voyage, but I have been using it for several years now. For a novice coming from a GUI its pretty daunting.
This may be a better option for those who don't want to get close and personal with the Linux command line:Puppy Linux Discussion Forum :: View topic - mpdPup - Simplified MPD Music Server/Jukebox - New Version!
I like Voyage, but I have been using it for several years now. For a novice coming from a GUI its pretty daunting.
Isolation / noise reduction on the USB power is a start but the other noise challenge is the common ground. Most PC's have their chassis connected to the power ground. Since USB ground is not isolated from the PC this becomes a real challenge to overcome. A "cheeter" connection breaking the ground connection at the power connector may do little to help because the internal circuit will probably have a filter that capacitively couples the power to the chassis.
ALSA update. I compiled and installed the latest version of ALSA (1.0.25) to see if it addressed any of the USB playback issues I have encountered. Unfortunately, no, they are still there.
Regardless, its probably a good move to update if you can. Don't make this your first Linux project, however. It can be quite daunting if you are not setup and have all the pieces sorted out.
Regardless, its probably a good move to update if you can. Don't make this your first Linux project, however. It can be quite daunting if you are not setup and have all the pieces sorted out.
Yes! I see nothing wrong with that new schematic.
There are a few things you could add, but most of them are probably overkill. The one thing that might be useful is a second capacitor across VBUS and GND after the ferrite bead filters but close to them on the PCB. Value would be between 0.1 µF to 0.01 µF. Since noise is your primary concern, that small addition should not hurt.
Other additions I've seen are a 6.2 V Zener to protect against excessive VUSB, but it seems unlikely that any modern USB Host would put out more than 5.25 V.
I see that you have ESD suppressors on the USB data lines. That seems like a good idea but I've never seen it or used it, so I can't say for sure.
Good work!
Which are your issues? The only thing that happens here occasionally is a 'hang up', probably due to a buffer undderun that sounds like a hanging CD.
Rüdiger
The latest Voyage supports NFS and CIFS. So adding Windows shares to fstab is no problem, but I had to additionally apt-get install winbind for some reason I can't recall.
The one problem I still have and Alex is aware of it is that a sample rate upshift from 44.1 to 88.2 confuses the firmware and it goes to some other sample rate. a pause and then play fixes the issue but it can be jarring. I wanted to see if the fixes in the latest Alsa addressed this in any way.
Does the issue occur when the sample rate shifts between discrete pieces of music, or only when the rate shifts during a piece?
I am now looking at whether the automatic rate feedback format detection logic in the alsa driver interacting with the widget firmware is causing the issue. So far the specific issue has never been reported with Win or OSX.
My plan is to investigate with two approaches:
1. Look at the alsa source code;
2. Use WireShark to see the USB exchanges between driver and firmware.
However it will take some time as I am busy with another project at the moment
Alex
My plan is to investigate with two approaches:
1. Look at the alsa source code;
2. Use WireShark to see the USB exchanges between driver and firmware.
However it will take some time as I am busy with another project at the moment
Alex
Interactions between mpd --> alsa uac2 driver ---> widget firmware
Hi Demian et al,
OK. The following is rather complicated but if you are interested enough you are welcome to read through. I still need to do the WireShark dump to confirm the following conjecture before forwarding the info to Daniel Mack.
1 In the alsa driver sound/usb/urb.c the following code fragment checks the rate feedback value:
if (unlikely(subs->freqshift == INT_MIN)) {
/*
* The first time we see a feedback value, determine its format
* by shifting it left or right until it matches the nominal
* frequency value. This assumes that the feedback does not
* differ from the nominal value more than +50% or -25%.
*/
shift = 0;
while (f < subs->freqn - subs->freqn / 4) {
f <<= 1;
shift++;
}
while (f > subs->freqn + subs->freqn / 2) {
f >>= 1;
shift--;
}
subs->freqshift = shift;
}
else if (subs->freqshift >= 0)
f <<= subs->freqshift;
else
f >>= -subs->freqshift;
if (likely(f >= subs->freqn - subs->freqn / 8 && f <= subs->freqmax)) {
/*
* If the frequency looks valid, set it.
* This value is referred to in prepare_playback_urb().
*/
spin_lock_irqsave(&subs->lock, flags);
subs->freqm = f;
spin_unlock_irqrestore(&subs->lock, flags);
} else {
/*
* Out of range; maybe the shift value is wrong.
* Reset it so that we autodetect again the next time.
*/
subs->freqshift = INT_MIN;
}
2 Now my hypothesis is that mpd changes the sampling rate when playing back mixed sampling rate albums without some sequence such as stop -> inform change freq -> restart. Thus alsa driver follows the above code fragment.
3. Now the rate feedback format used in the widget firmware (which proves to be compatible with Win and OSX) is 10.14 in 3 bytes, or 18.14 in 4 bytes.
4. The internal sampling freq format used in alsa uac2 is 16.16 in 4 bytes. So the CORRECT shift for the rate feedback format should be shift left by 2 bits, or multiply by 4.
4. Scenario when playing 96khz music and then skips to 44.1khz music:
Playing 96khz:
subs->freqn is 96khz or 96 * 2^16 in 16.16 format
rate feedback is 96khz or 96 * 2^14 in 18.14 format
Switch to 44.1khz without informing alsa:
subs->freqn is still 96hz or 96* 2^16
rate feedback is now 44.1 * 2 ^14
If rate feedback is shifted left by 2 bits:
44.1 * 2^14 *4 = 176.4 * 2 ^ 14
This is compared to (subs->freqn - subs->freqn / 4) or 72 * 2^16 or 288 * 2^14
This works.
,
If rate feedback is shifted by 3 bits (trial & error done in the code)
44.1 * 2^14 *8 = 352.8 * 2^14 which is bigger than 288 * 2^14 above.
Thus the code CORRECTLY decides that shift left by 2 bits is OK.
It then updates the actual frequency used:
subs->freqm = f;
5. So the scenario of 96khz ---> 44.1khz works.
6. Now the next scenario of 44.1khz skips to 96khz.
7. Playing 44.1khz:
subs->freqn is 44.1khz or 44.1 * 2^16
rate feedback is 44.1khz or 44.1 * 2^14
Now mpd changes sampling rate to 96khz without stop -> change freq -> restart sequence:
subs->freqn is still 44.1 * 2^16
rate feedback changes to 96khz or 96 * 2^14
Alsa code checks:
lower bound of 44.1 *2^16 - (44.1 * 2^16 /4) = 33.075 * 2^16 = 132.3 * 2^14
How many shifts are needed for 96 * 2^14 to be just < 132.3 * 2^14 ?
The answer is NONE, or 0.
The new computed freq is 96 * 2^14, or 24 * 2^16, or 24khz. This is obviously wrong. So the last section of the code rejects it and subs->freqm (the modified freq as opposed to the nominal freq of subs->freqn) is NOT changed. So rate feedback fails to sync.
8. To actually PROVE my hypothesis above, there are several steps required:
(a) check mpd code --> alsa driver to confirm that mpd does not inform alsa driver of change in sampling rate when skipping, or mpd informs, but alsa driver does not update subs->freqn accordingly etc.
(b) disable the uac2 driver's automatic feedback rate format detection and replace it with a fixed 18.14 format. (This will test whether it works with widget firmware, but it will probably break the alsa driver when using other soundcards which use a different format, such as 12.13 etc.)
9 If the above hypothesis is true, WireShark dump of the USB transactions will not help with the debugging, as the USB transactions are all corrrect.
10. It is interesting to note that with mpd, you can restore the sampling rate sync by stopping (or pausing) and restarting the stream. So a mod to mpd to ALWAYS issue a stop and restart before changing sampling rate should cure the problem as well.
Alex
Hi Demian et al,
OK. The following is rather complicated but if you are interested enough you are welcome to read through. I still need to do the WireShark dump to confirm the following conjecture before forwarding the info to Daniel Mack.
1 In the alsa driver sound/usb/urb.c the following code fragment checks the rate feedback value:
if (unlikely(subs->freqshift == INT_MIN)) {
/*
* The first time we see a feedback value, determine its format
* by shifting it left or right until it matches the nominal
* frequency value. This assumes that the feedback does not
* differ from the nominal value more than +50% or -25%.
*/
shift = 0;
while (f < subs->freqn - subs->freqn / 4) {
f <<= 1;
shift++;
}
while (f > subs->freqn + subs->freqn / 2) {
f >>= 1;
shift--;
}
subs->freqshift = shift;
}
else if (subs->freqshift >= 0)
f <<= subs->freqshift;
else
f >>= -subs->freqshift;
if (likely(f >= subs->freqn - subs->freqn / 8 && f <= subs->freqmax)) {
/*
* If the frequency looks valid, set it.
* This value is referred to in prepare_playback_urb().
*/
spin_lock_irqsave(&subs->lock, flags);
subs->freqm = f;
spin_unlock_irqrestore(&subs->lock, flags);
} else {
/*
* Out of range; maybe the shift value is wrong.
* Reset it so that we autodetect again the next time.
*/
subs->freqshift = INT_MIN;
}
2 Now my hypothesis is that mpd changes the sampling rate when playing back mixed sampling rate albums without some sequence such as stop -> inform change freq -> restart. Thus alsa driver follows the above code fragment.
3. Now the rate feedback format used in the widget firmware (which proves to be compatible with Win and OSX) is 10.14 in 3 bytes, or 18.14 in 4 bytes.
4. The internal sampling freq format used in alsa uac2 is 16.16 in 4 bytes. So the CORRECT shift for the rate feedback format should be shift left by 2 bits, or multiply by 4.
4. Scenario when playing 96khz music and then skips to 44.1khz music:
Playing 96khz:
subs->freqn is 96khz or 96 * 2^16 in 16.16 format
rate feedback is 96khz or 96 * 2^14 in 18.14 format
Switch to 44.1khz without informing alsa:
subs->freqn is still 96hz or 96* 2^16
rate feedback is now 44.1 * 2 ^14
If rate feedback is shifted left by 2 bits:
44.1 * 2^14 *4 = 176.4 * 2 ^ 14
This is compared to (subs->freqn - subs->freqn / 4) or 72 * 2^16 or 288 * 2^14
This works.
,
If rate feedback is shifted by 3 bits (trial & error done in the code)
44.1 * 2^14 *8 = 352.8 * 2^14 which is bigger than 288 * 2^14 above.
Thus the code CORRECTLY decides that shift left by 2 bits is OK.
It then updates the actual frequency used:
subs->freqm = f;
5. So the scenario of 96khz ---> 44.1khz works.
6. Now the next scenario of 44.1khz skips to 96khz.
7. Playing 44.1khz:
subs->freqn is 44.1khz or 44.1 * 2^16
rate feedback is 44.1khz or 44.1 * 2^14
Now mpd changes sampling rate to 96khz without stop -> change freq -> restart sequence:
subs->freqn is still 44.1 * 2^16
rate feedback changes to 96khz or 96 * 2^14
Alsa code checks:
lower bound of 44.1 *2^16 - (44.1 * 2^16 /4) = 33.075 * 2^16 = 132.3 * 2^14
How many shifts are needed for 96 * 2^14 to be just < 132.3 * 2^14 ?
The answer is NONE, or 0.
The new computed freq is 96 * 2^14, or 24 * 2^16, or 24khz. This is obviously wrong. So the last section of the code rejects it and subs->freqm (the modified freq as opposed to the nominal freq of subs->freqn) is NOT changed. So rate feedback fails to sync.
8. To actually PROVE my hypothesis above, there are several steps required:
(a) check mpd code --> alsa driver to confirm that mpd does not inform alsa driver of change in sampling rate when skipping, or mpd informs, but alsa driver does not update subs->freqn accordingly etc.
(b) disable the uac2 driver's automatic feedback rate format detection and replace it with a fixed 18.14 format. (This will test whether it works with widget firmware, but it will probably break the alsa driver when using other soundcards which use a different format, such as 12.13 etc.)
9 If the above hypothesis is true, WireShark dump of the USB transactions will not help with the debugging, as the USB transactions are all corrrect.
10. It is interesting to note that with mpd, you can restore the sampling rate sync by stopping (or pausing) and restarting the stream. So a mod to mpd to ALWAYS issue a stop and restart before changing sampling rate should cure the problem as well.
Alex
I have tried to duplicate the problem in Windows but none of the Windows programs I have tried so far switch tracks as fast. With MPD I can cue up a set of 5 second audio clips in different sample rates and they play without a hesitation. I have tried similar with the command line on Linux as well and hit the same problem. Is there a command line tool for playing audio tracks for Windows?
Do you need to accept such a wide different in sample rates when testing? There are really only 6 possible sample rates to support so it may work with a different algorithm that looks for only the possible valid options when the frequency changes.
I have access to 3 different async USB DAC + the AB1.1. I will be getting the MC6631 demo board soon. I can try a number of options with this.
Feedback format-is this a clue?
Feedback Format = 15.17 when its working
Feedback Format = 16.16 when its not working right
Do you need to accept such a wide different in sample rates when testing? There are really only 6 possible sample rates to support so it may work with a different algorithm that looks for only the possible valid options when the frequency changes.
I have access to 3 different async USB DAC + the AB1.1. I will be getting the MC6631 demo board soon. I can try a number of options with this.
Feedback format-is this a clue?
Feedback Format = 15.17 when its working
Feedback Format = 16.16 when its not working right