probably the easiest way to begin playing with Linux would be to install a full distribution such as "Ubuntu" (perhaps the "Ubuntu Studio" variant). But, for a dedicated "music machine", IMHO the best thing to do is to use a dedicated system already optimized for audio, such as Voyage MPD.
For the easiest doployment of Voyage MPD you'll need a LAN with a small router (providing DHCP) connected via Ethernet to the machine that will act as "music server" (WiFi configurations are possible too, but a bit more complex to set-up).
After configuration, the "music server" (the machine connected to the audio system) wil run as an appliance without the need for a local user interface (not even a display).
It will be remotely controlled from user interface(s) running on other machines/devices (even including hand-helds), namely MPD clients.
Among these, for use on a computer (another laptop/netbook or a desktop, with either Linux, Windows or MacOS/X), I'd recommend the nice, easy and featurefull "GMPC".
Last edited:
what values have you used for R and C?
(I like the possibility to directly drive my hearphones too, thus the R must be kept very small. I guess no more than a few ohm. What about f3? 40KHz could be ok?).
I'm still unsure about that...
There seems to be some, but overall I have mixed feelings. I'll let you know when I'll have some more definitive conclusions.
Is there any way to get a digital output (spif) from this audio widget?
I'm looking for a usb front end for my ezdac.
I'm looking for a usb front end for my ezdac.
My notes are here: http://www.diyaudio.com/forums/digital-source/185761-open-source-usb-interface-audio-widget-28.html#post2747950
I have not dug further into the limits but you may be hitting a brick wall with the ESS9023. The part meets or exceeds its published specs in this system. It does have some odd issues, overload is a specific one with the datasheet talking about a resistor (R15) affecting its clipping performance. It seems R15 sets the Vref for the DAC so its value and the optimized grounding of the associated caps will be critical. Keeping the digital and analog grounds isolated is challenging in a small device like this, especially when the analog power is derived from the digital side and there is no practical way to fully isolate the USB system from the DAC. This said I believe really close study of the PCB and its power and ground for the analog system, possibly even disconnecting all the analog ground connections and using a star ground (wirewrap wire would be OK on this side) could make a big difference in the final sound.
The spec sheet calls out the 4n7 caps on the output, and it also says the load must be higher than 10K (at least for the spec measurement) (no headphones here). The Nuforce U-dac that uses the same DAC chip uses a TI TPA4411 output amp, which helps a lot.
Its clear that the chip could benefit from some very careful supply and grounding help. However my experience suggests looking at the AKM4430 http://akm.lfchosting.com/datasheets/ak4430_f01e.pdf may get a better sound in this application (and possibly cheaper). Its only 16 pins and has a charge pump. The pinout is enough different that its not a drop-in.
You could add an I2S to SPDIF chip.
AK4104, DIT4192, CS8406 and others. I think the AKM datasheet suggested that its autodetect for everything but I didn't read it.
mmmh, may be I went a bit too far on this one with 47uF?
I'll try with smaller values too.makes sense... unfortunately I did not have suitable parts at hand. Maybe I should get and try those Panasonic. Indeed, having the cap after the v.reg. larger than the one before it is something I didn't quite like. OTOH, I wanted to have small Xc @ low freq (and plenty of stored energy) as close to the analog circuit as possible. I don't quite like the idea of audio signals circuit closing through a voltage regulator. I definitely prefer it to close (as much as possible...) through just a capacitor. Non-ideal as it can be, yet better than the complex active circuitry of any voltage regulator.
Oh, BTW: the link does not work! 🙁 Could you please provide a correct one?
so you just added the caps, without replacing the 0R with a true resistor (or inductor)?
sure, me too. 🙂
yup... it's time to gettin' serious, with a fully self-powered and fully dual-mono unit based on a couple of top-end DAC chips. Possibly also with optoisolators between uC and AB. 😉
The AB1.1 is nice and sounds quite well, but it's still far from the SQ of my current setup. 😉
Especially for what regards sound "richness" and "imaging". With my reference setup the latter in particular is kind of magic. Virtual image usually extends well over the limits of the speaker positions: (with some recordings) it may get close to a 180° sound stage, extending almost to the sides of the listening position! While still being perfectly stable, properly sized and focused (no, I don't use ambiophonics or any other sound processing).
On the contrary (all the rest being the same) with AB1.1 the image is always enclosed in the space within the speakers. 🙁 (and it's also somewhat less stable/clear/defined than my reference).
Last edited:
Hi Borge, Unix-man et al,
The "old" firmware (ie not the latest firmware I just built today), in the audio-widget-nik branch, uses, for uac1 24 bit USB and 24 bit i2S transferred to a 24 bit DAC. In uac2, it uses 32 bit USB and 24 bit I2S. The least significant 8 bits are truncated on transfer to the I2S bus.
My latest firmware (audio-widget-nik-2011-12-26.elf, which you can download from the code page), does FULL 32 bit transfers from USB to I2S to DAC, under UAC2.
So now it is up to the DAC to interpret the 32 bits coming in through the I2S bus 🙂
I have just tested it with my AB1 and it sounds exactly the same as the old firmware (which is expected).
So Borge: bumper to bumper I2S seems to be OK in the AW 😀
I will have to wait for George's 32 bit DAC to arrive to tell the difference 😉
Alex
Hi Alex,
sorry for the double posting... But the only way to test the bumper-to-bumper stuff is to scope the data line at word clock transitions. With known data (for example all 4 least significant bit being the same, and different from the MSBs) it is easy to see.
But to listen for a properly conveyed 32-bit LSB may be a bit tricky 🙂
Børge
sorry for the double posting... But the only way to test the bumper-to-bumper stuff is to scope the data line at word clock transitions. With known data (for example all 4 least significant bit being the same, and different from the MSBs) it is easy to see.
But to listen for a properly conveyed 32-bit LSB may be a bit tricky 🙂
Børge
HI Borge,
Please do the scope test to confirm that indeed the I2S has the correct 32bit data 🙂 It will be harder to test whether the DAC can interpret the last few bits of the 32 bit data though.
As far as I'm concerned, if I can't hear the difference, it makes no difference 🙂
Alex
Please do the scope test to confirm that indeed the I2S has the correct 32bit data 🙂 It will be harder to test whether the DAC can interpret the last few bits of the 32 bit data though.
As far as I'm concerned, if I can't hear the difference, it makes no difference 🙂
Alex
Great advice
Thanks UnixMan. This is exactly the kind of advice I was looking for. I will likely take this one step at a time, but I must admit, the dedicated appliance is where I would like to land. The concept is elegant in its simplicity. There is no extraneous hardware or software at the player. Also, I love the simplicity of the linear power supply, and the isolation from all the hdd/monitor etc.
Thanks UnixMan. This is exactly the kind of advice I was looking for. I will likely take this one step at a time, but I must admit, the dedicated appliance is where I would like to land. The concept is elegant in its simplicity. There is no extraneous hardware or software at the player. Also, I love the simplicity of the linear power supply, and the isolation from all the hdd/monitor etc.
Yes, a dedicated machine will my next step as well but for now I chose the fat lady - Fedora 16 KDE on an old laptop. Imagine that wireless worked right out of the iso file! Now I need some lightweight no fuss players.
Brgds
Greetings.
I received the sdr-widget AB-1.1 DAC. Great sound.
I would try external source to clock and DAC. Where is some information to make an external source for the AB-1.1?
I have doubts about the operation.
- J2: 3.3 V. --> VDD_SENSE VBUS_EN (off). (Then ADP151AUJZ_3.3 regulators OFF.)
Can be applied:
- J3: 3.3 V. 75 mA VDD_XO.
- J4: 3.3 V. 30 mA for analog DAC AVCC.
Would this be aproximately correct to begin?
I received the sdr-widget AB-1.1 DAC. Great sound.
I would try external source to clock and DAC. Where is some information to make an external source for the AB-1.1?
I have doubts about the operation.
- J2: 3.3 V. --> VDD_SENSE VBUS_EN (off). (Then ADP151AUJZ_3.3 regulators OFF.)
Can be applied:
- J3: 3.3 V. 75 mA VDD_XO.
- J4: 3.3 V. 30 mA for analog DAC AVCC.
Would this be aproximately correct to begin?
given that IIRC ES9023 is only a "24 bit" DAC, I guess it doesn't matter whether the 8LSB are truncated by the uC or by the DAC... 😀
If you use KDE, the natural choice would be "AmaroK"... but I'm afraid that doesn't exactly match your "lightweight no fuss" specs. 🙂
For a desktop based stand-alone player that match your requests you may want to have a look at gogglesmm (Goggles Music Manager).
Last edited:
At the highest level, USB is always 8-bit data. All data formats are expressed as collections of 8-bit bytes. Within the USB Audio Class, audio is sent as 8-, 16-, 24-, or 32-bit samples. A separate parameter specifies how many bits are valid, allowing 12-bit and 20-bit or other rare formats. The clock rate for USB data is fixed by the host, which is why UAC asynchronous uses rate feedback to control the effective sample rate.
Note that if you are running into USB bandwidth issues, then it might make sense to change from 32-bit samples to 24-bit samples, especially if your source data is only 24-bit anyway. Using 32-bit samples over USB just takes 33% more bandwidth with no benefit other than the fact that it's the same format when you do have 32-bit source material.
The I2S is completely independent of the USB format, with the obvious exception that the overall bandwidth cannot be exceeded. I2S is truly serial, with no requirement that the bit count be a multiple of 8. I2S Master and Slave can even use a different number of bits, with the understanding that the Word Clock will select the Most Significant Bit and any extraneous or missing bits will fall at the end of each word. The critical aspect is to align the MSB, although you might not be able to tell that it's off by one unless you have careful test data.
The bit clock rate of I2S determines the maximum sample rate, combined with the bit depth. If you have a low bit clock rate and a large sample bit depth such as 32-bit, then your maximum sample rate will be lower than if the bit depth were dropped to 24-bit. Using a higher bit clock rate allows the bit depth to be 32-bit without hitting any limits. Basically, the difference between the bit clock rate divided by the bit depth and the sample rate determines how many 'empty' bits there are between words on the I2S. At high sample rates, there may be 0 'empty' bits between words, and that's what people are concerned about. Different hardware will have different success at these extremes. Some serial peripherals will have no problem with back-to-back sample bits, while others will be flaky. Since the Audio Widget is fixed, and folks here have already reported success, then the only problem might be the DAC at the receiving end. Also, if future Audio Widget change the hardware for the I2S Master, then there might be opportunity for problems at the extreme.
Nah, amarok was about the first to be removed. Well, gogglesmm seemed to follow the rest of the pack with willingness to organize my media and so forth... I like vlc even though it isn't really lightweight. I would like something as pureplayer for linux that gives a sh*t about my media! It should really just ask what file or library do you want to play... Easy as that or can I just pipe a file to the device? In that case I can write my own script to use.
Brgds
Sorry folks, a bit OT... But still destilling what I need to check the AW out with my terms...
no, not necessarily.
oh... than you came to my own favourite "player":
Code:
AUDIODEV=hw:1,0 play *.flacThe command "play" is just a different name for "sox". Install sox and all of its plugins and you're done.
(setting the "AUDIODEV" env. variable is only needed if you want to output to a device different from the default one).