|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
74.69.242.210
| '); } else { document.writeln(''); } } else { document.writeln(''); } } else { document.writeln(''); } } // End --> |
Hi,I am trying to get networked linux box to support any sampling rate I send it up to 96k without having to use upsampling. I've been able to upsample to 96k and then send over the network via netjack, but I'd rather not listen to upsampled music if I can avoid it.
I have two other solutions that I have been mucking with on my linux box. One being MPD and the other Squeezeslave.
John, no matter what format I try (flac, wav, or wavepack), I've never been able to get squeezeslave to work with 96 kHz material. I've tried under windows with an M-Audio PCI card, and under linux with my Wavelength DAC. Have you been able to get Squeezeslave working at the 96k sampling rate?
Soundchekk, using MPD, I can get it to play 96k sampling rates, but only if I set that resolution in the MPD conf file, which then upsamples the music. If I use ecasound, is there a way to get it to play whatever sampling rate is sent? It seems to me that I have to specify a sampling rate in the ecasound configuration. The relevant section from my mpd.conf file is below.
audio_output {
type "pipe"
name "Pipe-Sox-ecasound"
command "ecasound -i:stdin -f:s24_le,2,44100 -o alsa,hw:1 2>/dev/null"
}EDIT:
Okay, I got MPD to work by using ALSA directly instead of ecasound, with the follwing relevant section from mpd.conf:audio_output {
type "alsa"
name "Wavelength Cosecant"
device "plughw:1,0" # optional
# device "hw:1,0"
auto_resample "no"
}Interestingly, hw:1,0 does not work. Is it because the Cosecant expects 24 bits and plughw will automatically pad to 24 bits?
Also, maybe its my imagination, but the alsa output sounds a little different from the ecasound output. How could that be, if they are both using alsa for the final output? One thing is for sure, ecasound must be using a large buffer compared to alsa direct because there is a few second lag in switching songs under ecasound.
Thanks for any help,
Alan
Edits: 07/02/09
Hi Allan.
1.The way I would run it:
On your audio client you'll mount your music directory via NFS.
MPD looks at the mount point for files. That'll be it. No need for
netjack or similar. Via Minion you control MPD from a remote host.
I strongly recommend to setup a harmonic network rate (either 100MBIT all,
or 1GB all. Avoid 100 to 1GB network connections - you can easily configure this - let me know if you need help here)
2. If you configure plughw Alsa outputs the data as it comes. It won't
negotiate with the device. To be able to use "hw" you need a properly
written driver for your card that is able to negotiate with the card.
Alsa will try to communicate with the card about sample rates etc.
That'll obviously fail if the driver is not supporting your device
properly.
3. Ecasound is a software written for "professional" usage and tuned to
lowest latency. It works best with a realtime kernel. It pretty
much does what - I guess - Amarra is doing - highly efficient code
optimised for audio. It further uses processor optimisation features
such as SSE for processing (see CPLAY). The great thing is that it is
a command line tool and therefore won't waste resources and can
be "misused" as audio-engine as done in our application.
MPD though uses the standard API to ALSA and is not pushed to the
limits when it comes to performance. This makes the difference.
Good to see that you realize differences in sound. With a
rt-kernel setup in place this should improve even further.
Your ecasound options can be further improved. You might try this:
ecasound -B:rt -r:89 -b:32 -f:s32_le,2,44100,i -i:stdin
-o:alsaplugin,1,0
When using different samplerates and ecssound as output-plugin for MPD
I switch outputs within MPD.
My own player recognises the formats and configures ecasound
automatically.
BTW: If you look at my kernel Wiki. I describe a way how to
install the latest ( and probably best ever) rt-kernel. This is not
a beginner task.
With a bit of experience it should work though.
Of course you can use the standard rt-kernel which you'll find in the
Ubuntu repo.
HINT: Checkout my RAMPLAYBACK advise in the MPD Wiki.
Hi soundchekk,
Thanks for the information. I have some further questions for you.
My music library is hung off of a XP box via windows shares, so I mount it via CIFS. Is there any benefit to mounting NFS instead of CIFS?
I think all of my network devices are operating at the same speed, but why do you recommend doing so?
I don't run a real-time kernel on the Fit-PC Slim because of the length of time it would take to compile the kernel. It only has a half gig of RAM and not much of a CPU. The main advantage of the Fit-PC is the clean USB ports and the ability to run off a battery. Will a real time kernel run on a low powered device like the Fit-PC?
I do run a real time kernel on one of my old CCRMA boxes, but maybe its time to update that to a more modern distribution like Ubuntu Studio. Then I can play with the kernel tweaks and RAM disks. I've been playing with Linux since its alpha and beta kernel days (the pre-Slackware SLS distribution finally made installation simple), so compiling a kernel isn't a problem.
I have been playing with MPD and Minion over the past day. It is working fine and switches sample rates on the fly when using alsa via plughw. You wrote: "When using different sample rates and ecasound as output-plugin for MPD I switch outputs within MPD. My own player recognizes the formats and configures ecasound automatically." This is intriguing. Are you doing this via the Minion plugin? Can you explain more about how you you have things configured to switch sample rates automatically?
Thanks,
Alan
I've run several different RT kernels on the Fit-PC, they work fine.
You actually compile stuff on the fit-PC itself? I never do that, I always compile on another machine (usually my old P4 2.4GHz machine, I think I have 7 OSes on there, the grub page is kind of large), doing a full kernel compile on the fit-PC would definitely take some time.
John S.
Hi John,
Compiling small stuff pretty quick on the Fit-PC. Though not compiling, last night I ran the Ubuntu do-release-upgrade script on the Fit-PC to get to the latest version of Ubuntu so I could try a real lime kernel. It took a while, and CPU percentages were up around 85 to 95 percent with most of the memory allocated, but I was listening to 24 96 resolution music the whole time via MPD and my USB DAC and I never heard a single hickup. Compiling the kernel on another machine is a good idea.
Alan
Hi John.Did you notice any differences on the FitPC when running a realtime kernel?
Did you try to boot the FitPC from net?
Edits: 07/04/09 07/04/09
1. NFS (Network File System) is a pure Linux2Linux filesystem.
Its performance "can" be better then CIFS or SMBFS.
This will depend on your setup.
I'd recommend to try a Linux File Server. (Many of the NASes around
are based on Linux. )2. If you have mixed transmission rates in the network, you'll have a lot
of negotiations and buffering ongoing. This should be avoided.
Try this: "ethtool -s eth0 autoneg off speed 100", if you e.g.want to
bring your GBit-eth-interface down to 100MBit. (sudo apt-get install ethtool)3. The rt-kernel should run on the FITPC. (I'll know soon)
There is no need to compile the kernel. No need to install
Ubuntu Studio.
It works on all Ubuntus (Jaunty) and Mints (Gloria). Just install it with "sudo apt-get install linux-image-2.6.28-3-rt linux-headers-2.6.28-3-rt" 07/03/09
4. Within MPD I configure multiple (ecasound-pipe)-outputs with different sample-rates, which I select via Minion.
If you feed MPD right into ALSA and plughw, you don't have to
take care about it.5. I've written my own little player (I called it "EcaSx") using Sox and
Ecasound.
The Sox package comes with an application called "soxi". This I use
to find out the file parameters to setup ecasound for playback.
EDIT: Hmmh. I need to check the ethernet tweak. I just brought my
GB/s-interface down to 100Mbit. Now the transfer of a 100Mb file takes 34s instead of 8.5s before.
Edits: 07/03/09 07/03/09
Hi Alan,
netjack runs at whatever sample rate the master is set to. If you start the master at 96 it runs at 96. If you start the master at 44.1 it runs at 44.1. What I'm not sure about is if you can change it on the fly. There is a control API which is supposed to allow you to control the master from an external program. I'm not sure if sample rate is one of the things that can be controlled. I think it is but I'm not sure. I need to study the documentation some more.
Squeeze slave only runs at 44.1 right now. Its not an inherant limitation but the developers got busy with other things and have not had the time to add multiple sample rates to it. My understanding is that getting it to go with multiple rates is not that hard. If I didn't have 9 projects already under way I'd probably take a stab at it.
Many modern sound devices on take data at a fixed format (usually either 24 o r32 bits) thus 16 bit through hw will not work, it has to go through plug. In this case its not resampling, just adding some extra zeros to make it fit.
I don't think any of my current devices will work without plug.
John S.
with hw0,0 you can be guaranteed nothing will be resampled because it has to be the exact bit length (16 or 24 I think?). Plug will convert to whatever the current situation demands. So if your dac is a 16 bit usb dac the hw should work fine because it shouldn't change (unless your soundcard, such as Creative, only supports 48khz). I believe hw is the best scenario, but in most cases for high def audio I think plug is necessary?
Post a Followup: