Re: Re: Re: Re: Re: Re: Which sound card is best for Linux audio?
so, in the end, you're recommending the Juli@ over all the other alternatives (including M-Audio, etc), aren't you?
so, in the end, you're recommending the Juli@ over all the other alternatives (including M-Audio, etc), aren't you?
Re: Re: Re: Re: Re: Re: Re: Which sound card is best for Linux audio?
Not really. I am just presenting its generally unknown technical merits compared to other envy24 cards. If you do not need 176.4kHz SPDIF-out with internal clock or analog playback/capture while clocked from external SPDIF, they bring no benefits to you.
For SPDIF-out clocked from external SPDIF, any reasonable bit-perfect card with SPDIF isolation transformer (if you need coax) supporting this mode will perform similarly. I do not know about any envy24 card with top quality multiple analog outputs (for HTPC). There are some with very good parameters, but the top quality you requested is provided by other products I guess (RME?).
It is all about your priorities, as always 🙂
UnixMan said:
so, in the end, you're recommending the Juli@ over all the other alternatives (including M-Audio, etc), aren't you?
Not really. I am just presenting its generally unknown technical merits compared to other envy24 cards. If you do not need 176.4kHz SPDIF-out with internal clock or analog playback/capture while clocked from external SPDIF, they bring no benefits to you.
For SPDIF-out clocked from external SPDIF, any reasonable bit-perfect card with SPDIF isolation transformer (if you need coax) supporting this mode will perform similarly. I do not know about any envy24 card with top quality multiple analog outputs (for HTPC). There are some with very good parameters, but the top quality you requested is provided by other products I guess (RME?).
It is all about your priorities, as always 🙂
Just checked - TOSLINK digital loopback of Prodigy192 + MI/ODI/O add-on can transfer 192kHz fs.
Re: Re: Re: Re: Re: Re: Re: Re: Which sound card is best for Linux audio?
of course. Anyway, I've just got a Juli@ off eBay for about 100 euros. I'll see soon how it'll perform in practice! 😀
of course. Anyway, I've just got a Juli@ off eBay for about 100 euros. I'll see soon how it'll perform in practice! 😀
Hi Soundcheck and Linux gurues,
I have the following trouble and maybe you could help me:
I am using this wonderful site http://www.avaxhome.ws/music/classical
Unfortunately, the majority of the files are APE, which my players won't read (I use FLAC). I installed "sound converter" but I does not work: I mean it looks like it works but the FLAC "converted" file is empty...any tips?
Thanks,
M
I have the following trouble and maybe you could help me:
I am using this wonderful site http://www.avaxhome.ws/music/classical
Unfortunately, the majority of the files are APE, which my players won't read (I use FLAC). I installed "sound converter" but I does not work: I mean it looks like it works but the FLAC "converted" file is empty...any tips?
Thanks,
M
as usual... when something goes wrong using a GUI, use the command line! 😉
this will convert from ape to wav:
mac file.ape file.wav -d
(if there are any problem doing it, you'll see it here... and likely it'll also tell you why).
Then, this will convert wav to flac:
flac --best --verify --delete-input-file file.wav
the "--best" (compression) option is optional. It will be compress a little bit more than default, but will be quite slower, too.
Alternatively, you can do it in one step using "shnconv" (from shntool):
shnconv -o flac file.ape file.flac
but then if there are problems you may miss the reason why.
Command line is way better for troubleshooting problems. But I think this is how you meant your remark anyway 🙂
Hi.
I had earlier discussions with these guys ( also Gordon Rankin from Wavelength ) at diyhifi.org about it.
These guys are claiming, they can measure anything. I doubt that
they have mega-bucks equipment at hand to cover all jitter aspetcs on the path.
Meanwhile Gordon Rankin is building himself stripped down Linux machines. Since
his async USB mode is not really the end of it.
What I am also saying - as many others do - since quite some time, that noise on the
USB link is awful. That's why I am using an Opticis Fibre connection fed by a 5V
battery-driven Teddy-Reg on the receiver side. This improves the situation greatly.
Jitter still exist though. I built a reclocker from ecdesigns which improved the situation even further.
When I was playing with his reclocker I discussed the awful impact of USB noise on his
USB receiver with him. That his reclocker wouldn't do unless the USB would be galvanically isolated.
I think galvanic isolation is must for serious PC audio with external devices.
Isolation transformers for mains supply in front of your gear - if you are not using batteries
like me - is also worth to think of. Mains are getting more and more polluted with HF stuff.
ecdesigns (John) from "Ulitimate DAC thread" is putting together a great galvanic isloated Toslink solution.
Cheers
I had earlier discussions with these guys ( also Gordon Rankin from Wavelength ) at diyhifi.org about it.
These guys are claiming, they can measure anything. I doubt that
they have mega-bucks equipment at hand to cover all jitter aspetcs on the path.
Meanwhile Gordon Rankin is building himself stripped down Linux machines. Since
his async USB mode is not really the end of it.
What I am also saying - as many others do - since quite some time, that noise on the
USB link is awful. That's why I am using an Opticis Fibre connection fed by a 5V
battery-driven Teddy-Reg on the receiver side. This improves the situation greatly.
Jitter still exist though. I built a reclocker from ecdesigns which improved the situation even further.
When I was playing with his reclocker I discussed the awful impact of USB noise on his
USB receiver with him. That his reclocker wouldn't do unless the USB would be galvanically isolated.
I think galvanic isolation is must for serious PC audio with external devices.
Isolation transformers for mains supply in front of your gear - if you are not using batteries
like me - is also worth to think of. Mains are getting more and more polluted with HF stuff.
ecdesigns (John) from "Ulitimate DAC thread" is putting together a great galvanic isloated Toslink solution.
Cheers
Some soundcard from RME also provide ADAT format which can isolate the noise. Their AES soundcard also has transformer isolation. But they should not help jitter as jitter refers to timing error?
ackcheng said:
That's correct.
Uli Brueggemann is using RME and ADAT afaik towards his FullDigiAmps. The sound
is extremely clean. However I am not aware of any DIY-ADAT receiver !?!?
I am not aware of any either. May have to rely on commercially avialable ones like rme ADI4DD. Since they are outside the PC, the PC noise is isolated still.
Hi folks.
I updated the MPD Wiki .
DIY AUDIO MPD Wiki
Perhaps you find some interesting stuff in there. Have a look at the updated configs
and related info. I think the sample rate conversion is worth to look at. I also played around
with different outputs and its settings. These you can select/deselect from e.g.Minion.
Cheers
Klaus
I updated the MPD Wiki .
DIY AUDIO MPD Wiki
Perhaps you find some interesting stuff in there. Have a look at the updated configs
and related info. I think the sample rate conversion is worth to look at. I also played around
with different outputs and its settings. These you can select/deselect from e.g.Minion.
Cheers
Klaus
soundcheck said:
Actually, some of them do...
Well, I don't agree with the way you say it, but the idea is correct... what noise could there be on USB ?
- Power supply noise (after all, it's direct from the PC's supply) : I'd certainly not build a USB-powered DAC...
- Ground loops : of course !!
- Clock noise : obviously any clock recovered from random IRQ timings isn't gonna be very clean... this applies to all isochronous usb gear like, most of what is on the market.
I think I'm gonna use some new interesting parts like IL261-3E (look it up on digikey) which is very nice, it's not an opto, rather a magnetocoupler (nanotech...) with quite amazing characteristics and in 1 IC you get 4ch in one direction and 1 ch in the other, which is perfect for I²S + master clock going the other way. Really a nice part.
Right now I've finished the verilog code and firmware for the USB and FIFO parts, the FPGA and the PC are communicating nicely over USB. All I need is to build a little DAC module and plug it... I'm impatient to hear the results !
peufeu said:
Might not be good enough. 😉 And taking the measurements is an art on its own.
Though I agree that these guys are not real beginners.
I remember the guys talking about their great gear just to wipe let's call it "empirical findings"
of the table. I am always very suspicious about commercial guys.
Look at the Agilent pages, great source for information related to our subject here.
The PC environment is just still too complex. Every firmware,software,hw upgrade can cause this or that change. It's like chasing ghosts.
Cheers
Guys, but why does everyone talk about isochronous USB transfer being software-clocked?
I have wondered for many months how USB isochronous actually works. Tonight I took the time and this is what I found. I may be wrong, of course 🙂
A description of a typical Intel USB controller is http://download.intel.com/technology/usb/UHCI11D.pdf . Take a look at Figure 3. The controller reads from a list of 1024 data frames every 1ms (HW clocked !), one frame a time. The list is maintained in RAM, read via DMA. The frame holds data from various transfers, BUT the isochronous transfer data (i.e. audio) is always the first (see Fig. 2). That means the isochronous data come to the USB device at a HW-clocked rate.
Now the UHCI driver is responsible for keeping the list updated. See function uhci_submit_isochronous http://lxr.linux.no/linux+v2.6.27.10/drivers/usb/host/uhci-q.c#L1231 . The urb structure holds urb->number_of_packets of the individual frames/packets, i.e. so many ms of audio data. In the code you can see the checks that URB does not exceed the 1024 frames limit, and the for loop assiging each packet in URB to the actual position in the frame list.
Note the flag TD_CTRL_IOC set to the last packet status on line http://lxr.linux.no/linux+v2.6.27.10/drivers/usb/host/uhci-q.c#L1323 . This tells the controller to generate interrupt when it processes this packet in the list. The interrupt ends up calling the function urb->complete which in effect controls preparation of new URBs http://lxr.linux.no/linux+v2.6.27.10/sound/usb/usbaudio.c#L683 .
If you dwelve into usbaudio.c, it shows that actually more than one URBs holding by default 8 packets each (configurable by the nrpacks param of the module) of audio data is copied to the frames list each "wakeup" of the driver. Minimum of 4-5ms latency (when nrpacks=1 http://alsa.opensrc.org/index.php/Usb-audio#Tuning_USB_devices_for_minimal_latencies ) is no major load for the system, the default setup is 8x higher (i.e. 8x fewer wake-ups).
I would say the USB path should not be overly sensitive to SW issues (the key 1ms is generated by HW, the driver itself requires no major time stress, similar numbers to PCI). Which is perfectly in line with empirical findings of the aforementioned article http://www.audialonline.com/html/articles/spdif_or_usb/4.php .
I have wondered for many months how USB isochronous actually works. Tonight I took the time and this is what I found. I may be wrong, of course 🙂
A description of a typical Intel USB controller is http://download.intel.com/technology/usb/UHCI11D.pdf . Take a look at Figure 3. The controller reads from a list of 1024 data frames every 1ms (HW clocked !), one frame a time. The list is maintained in RAM, read via DMA. The frame holds data from various transfers, BUT the isochronous transfer data (i.e. audio) is always the first (see Fig. 2). That means the isochronous data come to the USB device at a HW-clocked rate.
Now the UHCI driver is responsible for keeping the list updated. See function uhci_submit_isochronous http://lxr.linux.no/linux+v2.6.27.10/drivers/usb/host/uhci-q.c#L1231 . The urb structure holds urb->number_of_packets of the individual frames/packets, i.e. so many ms of audio data. In the code you can see the checks that URB does not exceed the 1024 frames limit, and the for loop assiging each packet in URB to the actual position in the frame list.
Note the flag TD_CTRL_IOC set to the last packet status on line http://lxr.linux.no/linux+v2.6.27.10/drivers/usb/host/uhci-q.c#L1323 . This tells the controller to generate interrupt when it processes this packet in the list. The interrupt ends up calling the function urb->complete which in effect controls preparation of new URBs http://lxr.linux.no/linux+v2.6.27.10/sound/usb/usbaudio.c#L683 .
If you dwelve into usbaudio.c, it shows that actually more than one URBs holding by default 8 packets each (configurable by the nrpacks param of the module) of audio data is copied to the frames list each "wakeup" of the driver. Minimum of 4-5ms latency (when nrpacks=1 http://alsa.opensrc.org/index.php/Usb-audio#Tuning_USB_devices_for_minimal_latencies ) is no major load for the system, the default setup is 8x higher (i.e. 8x fewer wake-ups).
I would say the USB path should not be overly sensitive to SW issues (the key 1ms is generated by HW, the driver itself requires no major time stress, similar numbers to PCI). Which is perfectly in line with empirical findings of the aforementioned article http://www.audialonline.com/html/articles/spdif_or_usb/4.php .
I am now using Linux based computer as my player
I'm now using a Linux based computer as my living room audio source, it's sound great, I think the most important issue is the sound card, I use a DIY sound decoder with a USB connected to the computer.
Marry Xmas.
I'm now using a Linux based computer as my living room audio source, it's sound great, I think the most important issue is the sound card, I use a DIY sound decoder with a USB connected to the computer.
Marry Xmas.
soundcheck said:
Nice start. Do you know what the state of mpd in the ubuntu repositories is? I didn't think that things like 24 bit output and better sample rate conversion had made it out of the betas yet.
I've become even more impressed with mpd after getting it running on my NSLU2. Flashing with the unslung firmware and ipkg get mpd, and presto! I'm running with audio out to a Twisted pear USB module. Very slick. (there's a howto for this on the nslu2 wiki). I don't know how big a library you can support before rescanning and building the DB is a problem, but I'm certainly not there with my still fairly small library. (~200 albums. I'm really slow at ripping....)
mpc has some features I didn't realize, though I suspect they're perfectly well documented. for example
mpc search genre XXXXX | mpc add
- Status
- Not open for further replies.