More details ....
I installed winXP inside Parallels desktop in the mac, and tried to play from the virtual machine.
I use Foobar, in the same setup as before.
In this configuration the metallic noise is present, but with two differences:
- it happens very soon, not after a long listening session
- it comes more quickly , and fades away more quickly
- the red and green leds are both ON ... that's normal, the control of the board is directly from xp, so the feedback end point is not used
I'm coming to think that the drivers from thesycon are quite peculiar, and probably not completely standard as regards the implementation.
What I'd like to try now is to use the ASIO drivers instead, inside the VM, and see what happens.
I installed winXP inside Parallels desktop in the mac, and tried to play from the virtual machine.
I use Foobar, in the same setup as before.
In this configuration the metallic noise is present, but with two differences:
- it happens very soon, not after a long listening session
- it comes more quickly , and fades away more quickly
- the red and green leds are both ON ... that's normal, the control of the board is directly from xp, so the feedback end point is not used
I'm coming to think that the drivers from thesycon are quite peculiar, and probably not completely standard as regards the implementation.
What I'd like to try now is to use the ASIO drivers instead, inside the VM, and see what happens.
No sweat starn02! Thanks for your test report.
I'm away from my debug setup for a few days, so I can't correlate what you're writing to what I've seen in the code lately. Are you able to see the debug messages ('+' and '-') on the RS232?
My Mac's keybaord has arrived and I hope to assemble it on Monday. Crossing my fingers that it works! I'm also borrowing a USB 2.0 analyzer from work. So what I'm hoping is to be able to debug on 3 platforms from the middle of next week. Until then I suggest we hold off a bit since my way of targeting stability on a Mac without owning one has been a bit too much shotgun-in-the-dark tactics with updates to experimental firmware
Could you commit your code with the REC and PLAY leds or upload the file you modified? I'd like to see the code you are referring to!
Cheers
Børge
I'm away from my debug setup for a few days, so I can't correlate what you're writing to what I've seen in the code lately. Are you able to see the debug messages ('+' and '-') on the RS232?
My Mac's keybaord has arrived and I hope to assemble it on Monday. Crossing my fingers that it works! I'm also borrowing a USB 2.0 analyzer from work. So what I'm hoping is to be able to debug on 3 platforms from the middle of next week. Until then I suggest we hold off a bit since my way of targeting stability on a Mac without owning one has been a bit too much shotgun-in-the-dark tactics with updates to experimental firmware
Could you commit your code with the REC and PLAY leds or upload the file you modified? I'd like to see the code you are referring to!
Cheers
Børge
My suggestions for testing ....
- the code that manages data to /from USB endpoints is actually made of 3 parts: one for play, one for feedback endpoint, and one for recording
- which parts actually work is controlled by two flags actually changed by USB commands
- if you can someway have a feedback about which parts are working and which are not (like in my modified code) you will see the different behaviour on different OS/driver combination. In my case I toggle two led off at the beginning of the loop code, and set them on if the code in the play or rec part is executed.
This is in my opinion the key to understand what's wrong. In the case of Windows, for instance, I believe that the information on the feedback endpoint is ignored (both rec and play are working, and I think the driver uses the rec samples number to adapt the size of playback endpoint ....
- the code that manages data to /from USB endpoints is actually made of 3 parts: one for play, one for feedback endpoint, and one for recording
- which parts actually work is controlled by two flags actually changed by USB commands
- if you can someway have a feedback about which parts are working and which are not (like in my modified code) you will see the different behaviour on different OS/driver combination. In my case I toggle two led off at the beginning of the loop code, and set them on if the code in the play or rec part is executed.
This is in my opinion the key to understand what's wrong. In the case of Windows, for instance, I believe that the information on the feedback endpoint is ignored (both rec and play are working, and I think the driver uses the rec samples number to adapt the size of playback endpoint ....
It's a good idea to differentiate between recording and separate endpoint for sample rate setting. This far I've focused on the separate feedback endpoint, but it's good to know if my code is actually executed on the various OSes.
It should be pretty easy to add some RS232 output message when usb_alternate_setting and usb_alternate_setting_out are modified by the host.
Børge
It should be pretty easy to add some RS232 output message when usb_alternate_setting and usb_alternate_setting_out are modified by the host.
Børge
Finally, my Mac is up and running! It's too late here now to do any proper tests, hope to do that in the the following days. Just confirmed that the Audio Widget plays and seems OK. Now I've got both Win7, Mac and Linux test platforms.
Here's something I'll try out in experimental fw next: There's actually room in the fw to create a 40.000 byte buffer where I plan to store gap, sent feedback and received packet lengths for 4.4s of music. Dumping it offline to a terminal over RS232 should be feasible. And I've got high hopes for the USB analyzer I'll borrow.
Oh, and here's a nice pic: The USB-I2S Module installed inside my CD player. (Alex and Roger, do you remember the DI-B board where you helped with the very first AW code? This is what it looks like now
Børge
Here's something I'll try out in experimental fw next: There's actually room in the fw to create a 40.000 byte buffer where I plan to store gap, sent feedback and received packet lengths for 4.4s of music. Dumping it offline to a terminal over RS232 should be feasible. And I've got high hopes for the USB analyzer I'll borrow.
Oh, and here's a nice pic: The USB-I2S Module installed inside my CD player. (Alex and Roger, do you remember the DI-B board where you helped with the very first AW code? This is what it looks like now
Børge
Attachments
Hi all! I just bought one of Borge's AB-1.2 DACs and connected it to a Raspberry Pi. He invited me to post my results here.
Executive summary: It works I'm listening to 24/96 FLAC files as I type this.
Background: I'm working on a music player based on the R-Pi Model B running Debian Wheezy. The player software is mpd. I have a 320GB USB hard disk connected for storage.
My prototype used a cheap USB DAC based on a USB1.1 Tenor chip. After a lot of experimentation, I got it playing bit-perfect at 16 bits, 44.1kHz, but couldn't get any higher without glitches. I did some research and found that the USB 1.1 part of the Pi's USB controller is a little broken.
However, the USB 2.0 part seems to work fine, and Debian Wheezy is based on the new Linux 3.2 kernel, and uses alsa for its sound system. So I figured I might have better luck with the AB-1.2 in its UAC2 mode. And I was right!
Well almost. There is one USB1.1 device left in the system, the keyboard. So I get the occasional audio glitch when pressing or releasing a key. But if I leave the keyboard alone, the sound seems perfect! I listened to a FLAC file of a low frequency sine wave for several minutes and couldn't hear any clicks or stutters.
Thank you Borge and all the other audio-widget developers, for giving me the hi-res audio output I wanted!
Executive summary: It works
I'm listening to 24/96 FLAC files as I type this.Background: I'm working on a music player based on the R-Pi Model B running Debian Wheezy. The player software is mpd. I have a 320GB USB hard disk connected for storage.
My prototype used a cheap USB DAC based on a USB1.1 Tenor chip. After a lot of experimentation, I got it playing bit-perfect at 16 bits, 44.1kHz, but couldn't get any higher without glitches. I did some research and found that the USB 1.1 part of the Pi's USB controller is a little broken.
However, the USB 2.0 part seems to work fine, and Debian Wheezy is based on the new Linux 3.2 kernel, and uses alsa for its sound system. So I figured I might have better luck with the AB-1.2 in its UAC2 mode. And I was right!
Well almost. There is one USB1.1 device left in the system, the keyboard. So I get the occasional audio glitch when pressing or releasing a key. But if I leave the keyboard alone, the sound seems perfect! I listened to a FLAC file of a low frequency sine wave for several minutes and couldn't hear any clicks or stutters.
Thank you Borge and all the other audio-widget developers, for giving me the hi-res audio output I wanted!
Last edited:
Can you write short instruction how to using R-Pi with audio-widget? It's very interesting theme.
there's no instruction needed; nothing pi specific, that is. the shipped kernel has uac2 support just fine.
some hubs do not pass audio thru (linux hub topology bug of some kind, on some usb1 or usb2 hubs). just connect AW direct to usb port on the pi. make sure the pi has enough stable 5v power! you are powering the AW thru the pi.
alsa just plain works. most of us run MPD and that just plain works.
wired ethernet (avoid wireless), usb AW on one usb port and I leave the other one free. that gives a pretty reliable config.
some hubs do not pass audio thru (linux hub topology bug of some kind, on some usb1 or usb2 hubs). just connect AW direct to usb port on the pi. make sure the pi has enough stable 5v power! you are powering the AW thru the pi.
alsa just plain works. most of us run MPD and that just plain works.
wired ethernet (avoid wireless), usb AW on one usb port and I leave the other one free. that gives a pretty reliable config.
I bought R-Pi without SD card and don't know which image select for guaranteed working with UAC2. Sorry, I'm not linux user
its safe to get the latest released raspian. there was one from the middle of december, that's what I used. that should be good; and if there is newer, so much the better.
I can't be sure that the 'usb elephant' bug has been fixed, but I have not noticed any -traffic- based lockups. insert/removal can crash things, but during normal operation, I just need i/o to always always work. so far, for using ethernet and usb-audio, I have not seen lockups. it streams music over nfs or samba using wired eithernet. for me, its behind powerline ethernet modules (known to be somewhat slow but still reliable) and that lets me put the pi and its dac in another room and still avoid wifi.
I do recommend getting mpd installed. you'll have to read up on what that means, but its usually not much more than 'apt-get install mpd' and a client (its front end) would be 'apt-get install ncmpc' (the client I use the most). there are webserver methods of controlling the music (playlist, shuttle control, etc) and even android/iphone clients to connect to mpd and control it.
I have a fully configured mpd system on sd-card. I would upload it if it was practical, but its an 8gig card (the size I recommend) and even compressed, it will be at least 4gig, I would guess. my upload speed is not really good enough to push up a 4gb file
I can't be sure that the 'usb elephant' bug has been fixed, but I have not noticed any -traffic- based lockups. insert/removal can crash things, but during normal operation, I just need i/o to always always work. so far, for using ethernet and usb-audio, I have not seen lockups. it streams music over nfs or samba using wired eithernet. for me, its behind powerline ethernet modules (known to be somewhat slow but still reliable) and that lets me put the pi and its dac in another room and still avoid wifi.
I do recommend getting mpd installed. you'll have to read up on what that means, but its usually not much more than 'apt-get install mpd' and a client (its front end) would be 'apt-get install ncmpc' (the client I use the most). there are webserver methods of controlling the music (playlist, shuttle control, etc) and even android/iphone clients to connect to mpd and control it.
I have a fully configured mpd system on sd-card. I would upload it if it was practical, but its an 8gig card (the size I recommend) and even compressed, it will be at least 4gig, I would guess. my upload speed is not really good enough to push up a 4gb file
As linuxworks says, there are no elite hacks required. Just use the latest Raspbian Wheezy image from here. Downloads | Raspberry Pi The audio driver in it supports the USB-I2S in UAC2 mode.
Then install mpd (it's available as a package for Raspbian: so you can just type "sudo apt-get install mpd"- assuming you have your Pi connected to the internet)
Edit the mpd.conf file as shown in the Audio Widget readme, to send output directly to the USB-I2S without resampling. Bingo!
You will need to do a bunch of little tweaks, for instance if you install a USB hard disk, you will need to edit /etc/mtab to get it to mount at boot. I have also had issues with log files filling up the SD card, which I still haven't figured out how to fix.
As far as I know, the "USB elephant" bug has been mitigated a lot by the latest OS releases, but it's not fixed. The problem, as far as I know, is that USB1.1 split transactions are mishandled. Due to excessive interrupt latency in the kernel, the USB stack sometimes misses the deadline for dealing with the second half of the split transaction. This probably causes some sort of error state in the controller that momentarily locks it up, affecting all USB traffic. The underlying issue is that the USB controller hardware doesn't do enough to help the OS, requiring unrealistic interrupt latency. The Broadcom boffins are talking about moving part of the USB stack onto the GPU core to fix this, but I doubt they will get round to it.
I tried lots of things when experimenting with the Tenor chip, including disabling clock management so the CPU runs full speed all the time. I didn't revert these changes this when moving to the USB-I2S, so it may be helping.
I'm considering moving my user interface over to the serial port, so there will be no USB1.1 devices left on the bus.
Once the project is done I will document it fully and maybe BitTorrent an image of the SD card. I wanted to find a way around the "USB elephant" before I went to the effort of building a casing for the system.
Then install mpd (it's available as a package for Raspbian: so you can just type "sudo apt-get install mpd"- assuming you have your Pi connected to the internet)
Edit the mpd.conf file as shown in the Audio Widget readme, to send output directly to the USB-I2S without resampling. Bingo!
You will need to do a bunch of little tweaks, for instance if you install a USB hard disk, you will need to edit /etc/mtab to get it to mount at boot. I have also had issues with log files filling up the SD card, which I still haven't figured out how to fix.
As far as I know, the "USB elephant" bug has been mitigated a lot by the latest OS releases, but it's not fixed. The problem, as far as I know, is that USB1.1 split transactions are mishandled. Due to excessive interrupt latency in the kernel, the USB stack sometimes misses the deadline for dealing with the second half of the split transaction. This probably causes some sort of error state in the controller that momentarily locks it up, affecting all USB traffic. The underlying issue is that the USB controller hardware doesn't do enough to help the OS, requiring unrealistic interrupt latency. The Broadcom boffins are talking about moving part of the USB stack onto the GPU core to fix this, but I doubt they will get round to it.
I tried lots of things when experimenting with the Tenor chip, including disabling clock management so the CPU runs full speed all the time. I didn't revert these changes this when moving to the USB-I2S, so it may be helping.
I'm considering moving my user interface over to the serial port, so there will be no USB1.1 devices left on the bus.
Once the project is done I will document it fully and maybe BitTorrent an image of the SD card. I wanted to find a way around the "USB elephant" before I went to the effort of building a casing for the system.
Last edited:
I'm finally up and running and able to do serious tests on Linux, PC and Mac! First of all I'm a total Mac newbie. I have a 2010 MacBook with a core 2 duo (I believe).
When the AW is just plugged in and I play music in iTunes, the Mac resamples. In UAC1 it resamples to 48, and in UAC2 it resamples to 192. Is there a way to tell it to not resample?
Børge
When the AW is just plugged in and I play music in iTunes, the Mac resamples. In UAC1 it resamples to 48, and in UAC2 it resamples to 192. Is there a way to tell it to not resample?
Børge
I have made a new FW release. It's basically a collection of bugfixes for the stable branch. See awx_20130112.zip
This release is very close to the audio-widget stable branch. It uses 16.16 UAC2 feedback, so Windows users must copy the attached .dll file to C:\Program Files (x86)\Audio-Widget (or similar).
The firmware works well on Linux and Windows. On Mac I need to do more testing.
A new debug feature lets you monitor the feedback system.
GPIO_03 = TP51 tracks spk_buf_in
GPIO_04 = TP50 tracks spk_buf_out
Use an oscilloscope and trig on GPIO_04 and see how GPIO_03. Any old 2-channel scope will do!
Børge
This release is very close to the audio-widget stable branch. It uses 16.16 UAC2 feedback, so Windows users must copy the attached .dll file to C:\Program Files (x86)\Audio-Widget (or similar).
The firmware works well on Linux and Windows. On Mac I need to do more testing.
A new debug feature lets you monitor the feedback system.
GPIO_03 = TP51 tracks spk_buf_in
GPIO_04 = TP50 tracks spk_buf_out
Use an oscilloscope and trig on GPIO_04 and see how GPIO_03. Any old 2-channel scope will do!
Børge