I found the error with UAC2 stability on the Mac. In the audio-widget-experimental branch the feedback format is set to what Linux recognizes as 16.16. With the AW firmware this format is NOT recognized by the Mac as proper feedback data.
However, UAC1 on my Mac does not work. The Mac doesn't change the frequency when the firmware detects excessive skew. While this isn't a big problem with functional Mac/UAC2, I'd still like to know why Mac/UAC1 is faulty and try to get it fixed. Any insight on feedback formats in Mac/UAC1 appreciated!
Børge
However, UAC1 on my Mac does not work. The Mac doesn't change the frequency when the firmware detects excessive skew. While this isn't a big problem with functional Mac/UAC2, I'd still like to know why Mac/UAC1 is faulty and try to get it fixed. Any insight on feedback formats in Mac/UAC1 appreciated!
Børge
The firmware at audio_widget_20130113.elf contains small bugfixes of the stable branch. It is checked into audio-widget. The feedback format is back at 15.17 so there is no need to change the Windows dll.
UAC2 is stable on Mac/Linux/Win-ASIO. UAC1 is stable on Linux and Windows. The bugs I looked at are:
- USB_WL redefined to USB_PRODUCT_NAME, AW came up as "SDR-Widget" on Mac/UAC1
- Safeguarding outer bonds in UAC2 code had typo/bug and can now execute as intended
- The code which replaces the old Linux quirk performs better on Win-ASIO
Cheers,
Børge
UAC2 is stable on Mac/Linux/Win-ASIO. UAC1 is stable on Linux and Windows. The bugs I looked at are:
- USB_WL redefined to USB_PRODUCT_NAME, AW came up as "SDR-Widget" on Mac/UAC1
- Safeguarding outer bonds in UAC2 code had typo/bug and can now execute as intended
- The code which replaces the old Linux quirk performs better on Win-ASIO
Cheers,
Børge
On the Mac, iTunes reads the system sample rate when it is first loaded up. If you change the sample rate while iTunes is running, it will continue to output at the old rate, and CoreAudio will resample to the new rate using a "standard quality" (probably not audiophile approved) algorithm.
To get output at the new rate, you have to quit iTunes and run it again.
When iTunes plays files of different sample rates to the rate it detected at startup, it resamples internally using a better quality algorithm than the CoreAudio default one.
Either way, I prefer MPD on the Raspberry Pi.
To get output at the new rate, you have to quit iTunes and run it again.
When iTunes plays files of different sample rates to the rate it detected at startup, it resamples internally using a better quality algorithm than the CoreAudio default one.
Either way, I prefer MPD on the Raspberry Pi.
Last edited:
linuxworks, scopeboy, thank you!
I successfully installed mpd and windows client, player started play mp3 file, but without sound. I'll try to understand what I made wrong.
my guess is that it finds the broadcom sound device, first. there's a way to force the usb device to be first and that makes life easier. first device is 'default' for many apps. I don't have the info handy (or my pi's) but I bet its the ordering that is going on. if you hear sound out of the onboard jack, then that was it.
also, you -can- edit the /etc/mpd.conf file and force the next device, by number.
also, you -can- edit the /etc/mpd.conf file and force the next device, by number.
Linuxworks, you should post the section of the mpd.conf that worked. This works on X86 for USB:
There is a setting that will force USB audio devices to start at 1
In /etc/modprobe.d/alsa-base.conf
options snd-usb-audio index=-2
Should force the USB audio device to load as hw:1
Code:
#
audio_output {
type "alsa"
name "USB_Short"
device "hw:1,0"
}
#There is a setting that will force USB audio devices to start at 1
In /etc/modprobe.d/alsa-base.conf
options snd-usb-audio index=-2
Should force the USB audio device to load as hw:1
Maybe it can help, alsa devices can also be called by name.
The device name can be found with aplay -l :
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AB12 [QNKTC USB DAC AB-1.2], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
The device name is just after the card number, here it is AB12
And the corresponding mpd.conf :
The device name can be found with aplay -l :
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AB12 [QNKTC USB DAC AB-1.2], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
The device name is just after the card number, here it is AB12
And the corresponding mpd.conf :
Code:
#
audio_output {
type "alsa"
name "usb"
device "hw:AB12"
}Thak you jdlvfr, 1audio and linuxworks!
I successfully played music from network storage. I'll test different sample frequencies, but 44100 sound is OK
Glad to hear it, nikkov!
As mentioned above, mpd will use the Broadcom audio device by default. The audio-widget readme file says how to configure mpd to use your USB audio interface. Basically it is like 1audio says above.
After some more listening, I've noticed occasional glitches (once per few minutes) when the USB keyboard is connected, even without touching any keys. I did some listening this morning with the keyboard disconnected, so all of the USB devices in the system were 2.0. I didn't hear any glitches.
As mentioned above, mpd will use the Broadcom audio device by default. The audio-widget readme file says how to configure mpd to use your USB audio interface. Basically it is like 1audio says above.
After some more listening, I've noticed occasional glitches (once per few minutes) when the USB keyboard is connected, even without touching any keys. I did some listening this morning with the keyboard disconnected, so all of the USB devices in the system were 2.0. I didn't hear any glitches.
people do report problems with keyboards. very odd, but with a headless player, its easy to work-around.
since its networked, once its booted and online, there is no need to have a keyboard attached. the only times I have a keybd on is when I'm doing the initial install. and then, you need hdmi out, too.
since its networked, once its booted and online, there is no need to have a keyboard attached. the only times I have a keybd on is when I'm doing the initial install. and then, you need hdmi out, too.
My ARM based Linux MPD player systems have never had a keyboard or a display connected.
File system built with debootstrap on a Intel Linux system, and kernel compiled without display support to have the full 1GB or 2GB RAM available to MPD.
Kernel is compiled without modules as everything needed are compiled into the kernel. ALSA source code are modified to optimize the USB transfers and reduce the IRQs from the normally 2000 pr. Second down to ca. 100...
USB adapter are now running with 32 milli second feedback timing (not the standard 1ms).
SSH are used to control the Linux systems either from iPad or MacBook Pro.
USB 2.0 and SATA RAID are galvanic isolated.
SATA RAID / SATA SSD are used due to DMA, speed and lower system resource usage as the NAS connection uses to much CPU and creates to much IRQs.
MPD is configured with onboard I2S and two USB adapters.
One or two or all three are selected / deselected from the MPD control client, MPoD, MPad or MPC.
Ahh that sounds like beautiful music. I ssh to Lynx to play files through aplay. It is very primitive. Now I'm becoming interested in the Rasberry PI approach. Maybe just add an LCD and a few buttons or IR sensor for IO.
RayCtech, this sounds very interesting Is there any way we could apply your modified source code to the Pi/Audio-Widget system?
Also, if you have been in the ALSA source, maybe you can shed some light on this:
When experimenting with my previous DAC, I found that I got glitches using the "hw" interface, but changing to "plughw" got rid of them, even though the plug module was supposed to be just passing the data through with no resampling or bit depth conversion.
So, does ALSA's "plug" module buffer more data somewhere in the kernel, where it could respond with a lower interrupt latency? Does it follow that using it on my current setup might help with the keyboard glitches?
I'm confident that plug won't resample or twiddle bits unless there is a genuine need for it, as I've verified bit-perfectness with it in the signal chain.
Is there any way we could apply your modified source code to the Pi/Audio-Widget system?Also, if you have been in the ALSA source, maybe you can shed some light on this:
When experimenting with my previous DAC, I found that I got glitches using the "hw" interface, but changing to "plughw" got rid of them, even though the plug module was supposed to be just passing the data through with no resampling or bit depth conversion.
So, does ALSA's "plug" module buffer more data somewhere in the kernel, where it could respond with a lower interrupt latency? Does it follow that using it on my current setup might help with the keyboard glitches?
I'm confident that plug won't resample or twiddle bits unless there is a genuine need for it, as I've verified bit-perfectness with it in the signal chain.
using an android phone (for example) you can control the playlist, shuttle and volume of mpd systems.
I used a cheap $100 nook color tablet and put cyanogen mod on it (trivially easy and reversable) and that sits literally ON my stereo shelf and gives a graphical (album art, too) display. touch screen for volume and even swipe left/right to skip back/forward. with that config, I have not found the -need- to have an attached lcd display (and I happen to love the 16x2 hitachi style 'easy' lcd displays).
tablets are getting so cheap, you can have one sit on your stereo shelf, one near the coffee table, etc etc. they all use wifi and all sync with each other (move the vol slider on one and the others update). pick it up from the stereo shelf, carry it to another room, use it there. freedom!
I used a cheap $100 nook color tablet and put cyanogen mod on it (trivially easy and reversable) and that sits literally ON my stereo shelf and gives a graphical (album art, too) display. touch screen for volume and even swipe left/right to skip back/forward. with that config, I have not found the -need- to have an attached lcd display (and I happen to love the 16x2 hitachi style 'easy' lcd displays).
tablets are getting so cheap, you can have one sit on your stereo shelf, one near the coffee table, etc etc. they all use wifi and all sync with each other (move the vol slider on one and the others update). pick it up from the stereo shelf, carry it to another room, use it there. freedom!
Attachments
btw, there is a rpi thread on diyaudio, and perhaps we should move the platform-specific discusion over there, to keep this channel clear and more on-topic:
http://www.diyaudio.com/forums/digital-source/201364-raspberry-pi-new-diyers-digital-hub.html
http://www.diyaudio.com/forums/digital-source/201364-raspberry-pi-new-diyers-digital-hub.html
I tested also the Qnktc and WaveIO and I do not remember the numbers for the separate adapters clearly, but I think I was able to reduce the IRQs from 2000 pr. second down to 1400 (maybe it was 1200).
The inbound IRQs (1000) are caused by the feedback setting in the adapter. The outbound I then reduced from 1000 to 400 or 200.
With the Amanero adapter I got down to a total of 140 IRQs pr. second as a total of inbound and outbound. 125 due to the feedback and ca. 15 due to data..
Now with my custom adapter that is based on a Amanero chipset I have reduced to the 50 area...
But the internal I2S (ARM CPU) uses DMA effectively and are down to 10 IRQs pr. second with a 3.5 ps jitter / 0 ppm clock - SPDIF output at +- 30 ppm.
Last edited:
Maybe a better question is: Where can I get this ARM board that has an ALSA driver for the onboard I2S peripheral? it would replace both the Pi and the USB-I2S.
I'll write about my Pi project in the other thread mentioned above when it's complete. I built a user interface based on a $16 backup camera monitor, an Arduino with an encoder and some buttons attached, and ncmpc (the console client for mpd) but I also like to use the Mpod client on my phone. Maybe I'll leave the UI out in the end.
I'll write about my Pi project in the other thread mentioned above when it's complete. I built a user interface based on a $16 backup camera monitor, an Arduino with an encoder and some buttons attached, and ncmpc (the console client for mpd) but I also like to use the Mpod client on my phone. Maybe I'll leave the UI out in the end.