A couple of remarks.
IMHO, for best SQ it's better to get rid of "pulseaudio" and use ALSA directly. You can temporarily disable pulseaudio or even completely uninstall the p.a. server package (not the libs, otherwise if you have Gnome you'll end up uninstalling just about every part of the GUI).
About resampling:
IME, always "upsamplig" in software to 24/192 (or 32/192) using SOX best algorithm, such as in:
gives the best SQ.
Using ALSA's libsrc, that is adding e.g. something like this:
to your ~/.asoundrc is also better than playing CD material directly at their native format.
Or you can enable libsrc resampling in MPD, if you use that.
Nevertheless, IME/IMHO SOX sounds even better than libsrc.
To use SOX within ALSA, you may try something like this:
(in case of problems, try to get rid of -q and replacing "-V0" with "-V3" or more for debuggin').
IMHO, for best SQ it's better to get rid of "pulseaudio" and use ALSA directly. You can temporarily disable pulseaudio or even completely uninstall the p.a. server package (not the libs, otherwise if you have Gnome you'll end up uninstalling just about every part of the GUI).
About resampling:
IME, always "upsamplig" in software to 24/192 (or 32/192) using SOX best algorithm, such as in:
Code:
sox *.flac -t alsa -b 32 hw:1,0 rate -v -I 192000Using ALSA's libsrc, that is adding e.g. something like this:
Code:
pcm.AW192 {
type plug
slave {
pcm "hw:1,0"
format S32_LE
channels 2
rate 192000
}
rate_converter "samplerate_best"
}
pcm.!default "AW192"Or you can enable libsrc resampling in MPD, if you use that.
Nevertheless, IME/IMHO SOX sounds even better than libsrc.
To use SOX within ALSA, you may try something like this:
Code:
# Use sox directly
pcm.soxd {
type file
slave {
pcm null
}
format "raw"
file "| /usr/bin/sox --single-threaded --combine sequence -q -V0 -t raw -c %c -b %b -r %r -s - -t alsa -b 32 hw:1,0 rate -v -I -a 192000"
}
Last edited:
Dear me!
I received my widget parts and am kind of ... ehm ... thrilled by the tiny legs of the µC. How did you manage to solder that? My smallest tip is 0.8mm and virtually as large as two or three legs of the atmel chip.
Seems like I have to glue the chip onboard first, and build a magnifying glass holder. Then de-coffeinate my last 20 years or so to get a steady hand
Rüdiger
I received my widget parts and am kind of ... ehm ... thrilled by the tiny legs of the µC. How did you manage to solder that? My smallest tip is 0.8mm and virtually as large as two or three legs of the atmel chip.
Seems like I have to glue the chip onboard first, and build a magnifying glass holder. Then de-coffeinate my last 20 years or so to get a steady hand
Rüdiger
I use:
- Microscope
- Extra flux
- SnPb solder
- Braid to remove excess solder
I usually fix one pin in a corner and then the opposite corner, getting the alignment right. Then, with highly liquid flux painted on all pins it is possible to pull a _small_ pearl of solder along one edge at a time. Finally, I use the braid to remove solder stuck between the last 2-3 pins.
With a very steady hand, thin solder and a thin tip it is also possible to touch the individual pins. I use Metecal soldering irons with good temp control.
Good luck!
Børge
- Microscope
- Extra flux
- SnPb solder
- Braid to remove excess solder
I usually fix one pin in a corner and then the opposite corner, getting the alignment right. Then, with highly liquid flux painted on all pins it is possible to pull a _small_ pearl of solder along one edge at a time. Finally, I use the braid to remove solder stuck between the last 2-3 pins.
With a very steady hand, thin solder and a thin tip it is also possible to touch the individual pins. I use Metecal soldering irons with good temp control.
Good luck!
Børge
Dear me!
I received my widget parts and am kind of ... ehm ... thrilled by the tiny legs of the µC. How did you manage to solder that? My smallest tip is 0.8mm and virtually as large as two or three legs of the atmel chip.
Seems like I have to glue the chip onboard first, and build a magnifying glass holder. Then de-coffeinate my last 20 years or so to get a steady hand
Rüdiger
This Surface Mount Soldering 101 Video should help
Confriming WinXP understandings
Hi
I have just finished reading thread from start to finish.
First I salute this effort. Open source collaboration is excellent.
I am interested in moving to async USB2 in my WinXP environment and want to confirm my understanding before jumping in with Børge's hardware. If I understand correctly, with native XP I can use it, but will be limited to 96.
While there is currently no open source Win USB2 driver, it is possible that there are licensed drviers that support this system. I currently use AQVOX ASIO driver with excellent results on CMP2/CPLAY driving a PCM2706 converter. I understand the AQVOX driver supports USB1.1 and it drives their own USB2 dac at 196. I wonder if anyone has tried this combination on this project hardware?
Also, a note for Turban as you use WinXP. You might be interested in the CMP2 thread cMP² | Main / HomePage . I saw the heated debate with RocketScientist about what casues jitter/SQ from the OS. We have discovered that even with a great ASIO driver and hdw platform, startling changes in SQ can be achieved by reducing the OS to the min. We currently run XP stripped down to 35mb so that it boots with nothing but the essentials to support the player GUI and read WAV files into memory. SQ improvement over a full XP image is unbelieveable. We use dedicated linear power supplies on every consumer in the PC, the USB converter and the DAC often with shunt regs to great advantage.
My concept is to replace my PCM2706 converter with Børge's hardware. I will add all the best power supplies I can design to attempt reference grade SQ. I run a TDA1541a NOS DAC with very nice 6np2 tube output with lots of ECDesigns concept. It would be interesting to compare the ESS DAC to this setup driven by your ATMEL converter.
I am not a UNIX guy, so I wanted to know how much risk I am taking on without the option of going to UNIX to solve firmware loads. I suppose I should try a UNIX partition to do an A/B comparison to tricked out CMP on XPlite.
Hi
I have just finished reading thread from start to finish.
First I salute this effort. Open source collaboration is excellent.
I am interested in moving to async USB2 in my WinXP environment and want to confirm my understanding before jumping in with Børge's hardware. If I understand correctly, with native XP I can use it, but will be limited to 96.
While there is currently no open source Win USB2 driver, it is possible that there are licensed drviers that support this system. I currently use AQVOX ASIO driver with excellent results on CMP2/CPLAY driving a PCM2706 converter. I understand the AQVOX driver supports USB1.1 and it drives their own USB2 dac at 196. I wonder if anyone has tried this combination on this project hardware?
Also, a note for Turban as you use WinXP. You might be interested in the CMP2 thread cMP² | Main / HomePage . I saw the heated debate with RocketScientist about what casues jitter/SQ from the OS. We have discovered that even with a great ASIO driver and hdw platform, startling changes in SQ can be achieved by reducing the OS to the min. We currently run XP stripped down to 35mb so that it boots with nothing but the essentials to support the player GUI and read WAV files into memory. SQ improvement over a full XP image is unbelieveable. We use dedicated linear power supplies on every consumer in the PC, the USB converter and the DAC often with shunt regs to great advantage.
My concept is to replace my PCM2706 converter with Børge's hardware. I will add all the best power supplies I can design to attempt reference grade SQ. I run a TDA1541a NOS DAC with very nice 6np2 tube output with lots of ECDesigns concept. It would be interesting to compare the ESS DAC to this setup driven by your ATMEL converter.
I am not a UNIX guy, so I wanted to know how much risk I am taking on without the option of going to UNIX to solve firmware loads. I suppose I should try a UNIX partition to do an A/B comparison to tricked out CMP on XPlite.
Thanks for the tip wlowes! I will look into the thread. Keep us in the loop with your findings. My crappy winxp isn't really fast enough to stream the bits as there is artifacts as sudden silence for a fraction of a sec and pops (you name it) depending on what I do with the rest of the system. The linux system behaves better though.
Brgds
Brgds
Hi Wolwes,
Hat of to you for going through 551 posts
Last things first: You don't need Unix experience at all. I compile and install firmware on a Windows platform. I do use Cygwin, but a single command gets the firmware compiled. Git was new to me, but it would also have been so with my existing Unix experience.
Because of limited endpoint buffer length (512 bytes) in the Atmel MCU, UAC1 can only go to 24/48, not 24/96 as would have been the case with 1024 byte enpoint buffers. I've told their decision makers about it, and who knows. But don't hold your breath. Basically they ignore audio which isn't stored on an Apple device.
The PCM2706 isn't asynchronous. I used the PCM2705 (or another sibling, forgotten which) as a USB-SPDIF bridge a while ago. Then an SRC4392 took this SPDIF and SPDIF from other sources and muxed it onto an I2S bus. The whole setup plays fairly well but it regenerates MCLK (twice!), and is hence useless for Hi-End use. Let me know if anybody needs SRC4392 control C code.
Your points on OS vs. SQ is interesting. Guys, let's not start the discussion again. Instead, let's patch the code with a fault detector and couple it with uncompressed sources. Then it should be possible to judge quality degradation from different system parameters.
I suggest R[n]=R[n-1]+1, L[n]=fullscale-R[n], and that the last line of code before the I2S output checks wheter these two are indeed the case, increments one counter for each test fault, and dumps that counter to a display. Alex, do you think that can be made to work fast enough? Obviously, the checks would look slightly different for 16 and 24 bit sources.
Børge
Hat of to you for going through 551 posts
Last things first: You don't need Unix experience at all. I compile and install firmware on a Windows platform. I do use Cygwin, but a single command gets the firmware compiled. Git was new to me, but it would also have been so with my existing Unix experience.
Because of limited endpoint buffer length (512 bytes) in the Atmel MCU, UAC1 can only go to 24/48, not 24/96 as would have been the case with 1024 byte enpoint buffers. I've told their decision makers about it, and who knows. But don't hold your breath. Basically they ignore audio which isn't stored on an Apple device.
The PCM2706 isn't asynchronous. I used the PCM2705 (or another sibling, forgotten which) as a USB-SPDIF bridge a while ago. Then an SRC4392 took this SPDIF and SPDIF from other sources and muxed it onto an I2S bus. The whole setup plays fairly well but it regenerates MCLK (twice!), and is hence useless for Hi-End use. Let me know if anybody needs SRC4392 control C code.
Your points on OS vs. SQ is interesting. Guys, let's not start the discussion again. Instead, let's patch the code with a fault detector and couple it with uncompressed sources. Then it should be possible to judge quality degradation from different system parameters.
I suggest R[n]=R[n-1]+1, L[n]=fullscale-R[n], and that the last line of code before the I2S output checks wheter these two are indeed the case, increments one counter for each test fault, and dumps that counter to a display. Alex, do you think that can be made to work fast enough? Obviously, the checks would look slightly different for 16 and 24 bit sources.
Børge
My issue is not about SQ but about a crappy old PC that can't cope with the speed of the stream at all times. There between the SQ is very good. It is now a 8 years old, 2,8GHz CPU with 2G RAM. It was top notch almost when new. The XP installation has seen many changes of SW and HW through the years but still - it's pretty clean in the device manager. No, really this isn't much to use as an argument in any debate and I should really retire it from being a transport.
Brgds
Brgds
that's ridicolous!
How would you need a supercomputer just to copy bits from an HDD to an USB interface?
Guys, you need to change your mind... and OS! Clearly, what you are trying to use isn't able to do any kind of real-time processing. And does waste most of its hardware resources, too.
The PC that I use as audio source (as well as "HTPC") is older than yours. It has a Pentium E5200@2.50GHz with 1GB of RAM. Yet it's perfectly able to play audio without a single glitch ever, while upsampling CD material to 32/192 using the best (and heaviest) resampling algoritms from sox or libsrc. All this without even getting close to its hardware limits!
And I do this using a full-featured, general purpose desktop (TDE, that is KDE 3.5, which I still prefer over newer interfaces), not some stripped-down dedicated system.
I can freely use the system for any other purpouse while listening to music without creating any problem to the audio. I have to badly overload the system with lots of processes and some really heavy processing before getting a single glitch (underrun).
Using "Voyage MPD | Voyage Linux" I can do the same heavyweight real-time audio processing while playing without glitches even on my almost 10 years old "Centrino" laptop.
If you don't do upsamplig in software (from later tests I've found out that the Sabre on AB1.1 seems to play fairly well without that also with 44.1/16 CD material), you can get along with the least powerful embedded system, such as an old "VIA" (or the one provided from Voyage, etc).
It's bad software that you need to get rid of, not your still perfectly good and viable hardware!
Hi all,
As Borge said, we do not wish to start a lot of "heated debates" about jitter/distortion from OS, upsampling vs no-resampling, Linux vs Windows, 44.1/16 vs 192/24 etc.
To each his/her own The hurdle to change one's mindset (or OS) is often tremendous. And it becomes very difficult if ego is involved !!!
What we can do, and we encourage all to help, is to make the hurdle lower, eg:
1. show and tell (and listen) to AB1.1 or USB9023 under different OS'es and different drivers/playback software, with/without upsampling etc.;
2. make it easier for Windows folks to experience Linux. In the sister project to the audio-widget, the sdr-widget (for ham radio), we are making a USB stick Linux image that Windows users can boot the OS and configured software by just plugging in and booting the USB stick; Similarly, I think the Voyage MPD can be squeezed into a bootable USB stick.
wrt to the question of 96/192khz 24 bit uac2 for Windows, some of us have tested the audio-widget with experimental uac2 drivers and we have demonstrated technical compatibility. However, if you want to use commercially available 3rd party uac2 Windows drivers, you have to negotiate your own terms, fees and royalty. What I can tell you is that it will run into $$$$$ and NDA etc.
We are still waiting for volunteers to write an open source uac2 driver for Windows it may or may not happen over the next couple of years
In the meantime, we are waiting for new versions of Android to support uac2. Android is based on the Linux kernel and the latest (2.8.38 or later) Linux kernel supports uac2 natively. So when Android catches up (may be in Ice Scream Sandwich ?), there will be millions of Android phones and tablets that can play 192/24 async uac2 music through the audio-widgets.
Alex
As Borge said, we do not wish to start a lot of "heated debates" about jitter/distortion from OS, upsampling vs no-resampling, Linux vs Windows, 44.1/16 vs 192/24 etc.
To each his/her own
The hurdle to change one's mindset (or OS) is often tremendous. And it becomes very difficult if ego is involved !!!What we can do, and we encourage all to help, is to make the hurdle lower, eg:
1. show and tell (and listen) to AB1.1 or USB9023 under different OS'es and different drivers/playback software, with/without upsampling etc.;
2. make it easier for Windows folks to experience Linux. In the sister project to the audio-widget, the sdr-widget (for ham radio), we are making a USB stick Linux image that Windows users can boot the OS and configured software by just plugging in and booting the USB stick; Similarly, I think the Voyage MPD can be squeezed into a bootable USB stick.
wrt to the question of 96/192khz 24 bit uac2 for Windows, some of us have tested the audio-widget with experimental uac2 drivers and we have demonstrated technical compatibility. However, if you want to use commercially available 3rd party uac2 Windows drivers, you have to negotiate your own terms, fees and royalty. What I can tell you is that it will run into $$$$$ and NDA etc.
We are still waiting for volunteers to write an open source uac2 driver for Windows
it may or may not happen over the next couple of years In the meantime, we are waiting for new versions of Android to support uac2. Android is based on the Linux kernel and the latest (2.8.38 or later) Linux kernel supports uac2 natively. So when Android catches up (may be in Ice Scream Sandwich ?), there will be millions of Android phones and tablets that can play 192/24 async uac2 music through the audio-widgets.
Alex
Its very possible to make Voyage MPD boot and operate from a USB stick. I do that with the variation I built for the Auraliti players all the time. The boot is slow but once its running all is fine. You will need to have all the desired drivers for possible hardware built into it and the content should be on a separate drive.
Demian
yup, I guess that may be the problem. Usually XP runs happily on way much older hardware...I agree UnixMan... But I want XP as well and yes, the HW SHOULD be enough - so maybe a fresh install might do it. So this installation is ripe for retirement
done...
sure it can (though as said by Demian it's really slooooow to boot off an USB stick). Of course it still need some configuration. It does not play right out of the box.
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