NetJack2 success!
Okay, this is much better. I hooked up my Atom-based netbook (Acer Aspire One) running vanilla Ubuntu 8.0.4 with a Twisted Pear USB dongle as the master, and used the same desktop machine (Core3Duo, Ubuntu 7.10) as the playback slave. Mpd has been playing on the slave feeding the netbook for a few hours with no hint of trouble, even during normal light desktop/surfing use. Same network setup - the netbook is on another port in the same switch as the windows box was.
I've only had jconv in the loop for a brief time, but it's been fine over that time.
So, it looks like Jack on windows still has some issues. I don't have a quick way to try multichannel and/or higher sample rates, but at least for stereo 44.1, netjack looks perfectly viable on Linux.
Okay, this is much better. I hooked up my Atom-based netbook (Acer Aspire One) running vanilla Ubuntu 8.0.4 with a Twisted Pear USB dongle as the master, and used the same desktop machine (Core3Duo, Ubuntu 7.10) as the playback slave. Mpd has been playing on the slave feeding the netbook for a few hours with no hint of trouble, even during normal light desktop/surfing use. Same network setup - the netbook is on another port in the same switch as the windows box was.
I've only had jconv in the loop for a brief time, but it's been fine over that time.
So, it looks like Jack on windows still has some issues. I don't have a quick way to try multichannel and/or higher sample rates, but at least for stereo 44.1, netjack looks perfectly viable on Linux.
soundcheck said:
Yeah, ecasound is pretty amazing. A dizzying array of capabilities - so many that it probably obscures it's basic utility. Being command line only it's a bit cumbersome to experiment with sometimes, but once you have your setup pinned down and wrapped in a script ecasound is ideal for a headless audio setup.
soundcheck said:
THX ZMN. I overlooked these. Hope you managed to get ot going.
The MPD compiled from csv works great. But, I have not figured out why the sound deteriorated (crackles) as much as it did when using the real time kernel suggestion, in combination with pulseaudio instead of ALSA as output device for MPD (on Ubuntu 8.10). I have tried several rt priority settings and that seemed not to help much.
Hi,
I've searched the thread and found nothing (at least nothing I could understand
) how brutefir is to be integrated in the Linux audio chain.
I'm a linux noob and just figured how to setup ubuntu studio 8.04 with rt-kernel, installing mpd that routes into alsa and command it via Minion. Just found Klaus' mpd-wiki that claims to use a special command to enable real time capabilities.
I'm trying to get a decent soundcard, meanwhile it plays through an Intel ICH4 onboard soundchip which uses an ADxxxxx, and it sounds better than I thought it would.
However, in the future I'm planning to try room correction with acourate, and I need to know how brutefir integrates into all that. Note that I need to keep mpd because of the client-server stuff it provides.
I have to confess that I don't understand the major part of the brutefir documents.
Thanks and thanks for that beautiful thread anyway,
Rüdiger
I've searched the thread and found nothing (at least nothing I could understand
) how brutefir is to be integrated in the Linux audio chain.I'm a linux noob and just figured how to setup ubuntu studio 8.04 with rt-kernel, installing mpd that routes into alsa and command it via Minion. Just found Klaus' mpd-wiki that claims to use a special command to enable real time capabilities.
I'm trying to get a decent soundcard, meanwhile it plays through an Intel ICH4 onboard soundchip which uses an ADxxxxx, and it sounds better than I thought it would.
However, in the future I'm planning to try room correction with acourate, and I need to know how brutefir integrates into all that. Note that I need to keep mpd because of the client-server stuff it provides.
I have to confess that I don't understand the major part of the brutefir documents.
Thanks and thanks for that beautiful thread anyway,
Rüdiger
I just do not see the advantage of real-time kernel for pure audio playback, where overall latency does not matter. The RT kernel as provided e.g. by Ubuntu Studio is known to have problems with some alsa drivers (e.g. midi in ice1724), other SW has issues with it too.
Instead of minimizing latencies (and putting thus more strain on the machine), I would choose the maximum latency the card offers (period size in alsa, nrpacks param of the usb audio module), thus minimizing IRQs and giving the upstream maximum time for preparation of the next batch with audio data. RT mode is certainly an advantage too, but it is available in non-RT kernel too.
Instead of minimizing latencies (and putting thus more strain on the machine), I would choose the maximum latency the card offers (period size in alsa, nrpacks param of the usb audio module), thus minimizing IRQs and giving the upstream maximum time for preparation of the next batch with audio data. RT mode is certainly an advantage too, but it is available in non-RT kernel too.
@pofman:
We are not talking in-out latency over here. I am talking inter-process latencies!
Quite some process chains need to get rt-priorities to run properly ( without Xruns as e.g. reported by zmn two posts earlier.)
Even though the CFS scheduler is supposed to be "completely fair" to all
processes. It's somehow not working in all cases/configs - especially if you're setting up process chains..
There is a good chance that you'll get better sound by running rt-priorities.
on your process. Depending on your interface, the sound can improve by using rt-prios.
@zmn:
Your problem is a typical problem with pulseaudio.
It is kind of tricky to get it properly integrated into a realtime chain .
In general you need to exactly know what priority to put on each of the processes involved in your chain. They all depend on each other. If one thread or process in the chain don't have rt-priorities or better the right rt-priorities, a certain thread won't get the priority to feed another thread. This will cause Xruns in case buffer sizes are not properly set.
It'll most probably help to play with increasing certain buffers in the chain.
Using e.g. Jack in a realtime chain works much more stable.
The most easiest solution is to keep the chain as short as possible.
@ Onvinyl
The most people I know ( incl. Uli Brueggemann) are running brutefir via script.
As you might have read, some time ago I tried to get it working with MPD connected
via fifo. I had it working with some limitations realted to the fifo handling.
Perhaps I should write something in the Wiki about it.
Cheers
We are not talking in-out latency over here. I am talking inter-process latencies!
Quite some process chains need to get rt-priorities to run properly ( without Xruns as e.g. reported by zmn two posts earlier.)
Even though the CFS scheduler is supposed to be "completely fair" to all
processes. It's somehow not working in all cases/configs - especially if you're setting up process chains..
There is a good chance that you'll get better sound by running rt-priorities.
on your process. Depending on your interface, the sound can improve by using rt-prios.
@zmn:
Your problem is a typical problem with pulseaudio.
It is kind of tricky to get it properly integrated into a realtime chain .
In general you need to exactly know what priority to put on each of the processes involved in your chain. They all depend on each other. If one thread or process in the chain don't have rt-priorities or better the right rt-priorities, a certain thread won't get the priority to feed another thread. This will cause Xruns in case buffer sizes are not properly set.
It'll most probably help to play with increasing certain buffers in the chain.
Using e.g. Jack in a realtime chain works much more stable.
The most easiest solution is to keep the chain as short as possible.
@ Onvinyl
The most people I know ( incl. Uli Brueggemann) are running brutefir via script.
As you might have read, some time ago I tried to get it working with MPD connected
via fifo. I had it working with some limitations realted to the fifo handling.
Perhaps I should write something in the Wiki about it.
Cheers
soundcheck said:
As I understand it, before I can run it (be it via a scirpt or whatelse), I have to specify where brutefir sits in the chain.
Out of a feeling, I'd say between MPD and the ALSA soundcard drivers.
Next step would be to figure out, how the brutefir.conf (or the like) has to be altered in order to achieve my needs. Here is the point where I am too noob to understand all the options correctly.
So you are saying, the performance is not optimal (soundwise), if we connect mpd and brutfir?
Rüdiger
Hi there.
I updated the brutefir setup Wiki with an "mpd-section".
The problem - if you start and stop mpd playback, mpd flushes the fifo which makes the brutefir daemon die, because it sees a bad file descriptor.
This needs to be solved on either of the ends. Either brutefir becomes immune against bad file-
descriptors on the fifo or MPD stops flushing the fifo on start and stop. phofman had an idea how to tackle this. I havn't really looked further into it.
The current workaround is to start playback before you start brutefir.
Once the playlist is playing in mpd next/prev/pause functions can be used without killing brutefir.
Let me know if the Wiki description works.
Would be great if some hackers around here can jump into this discussion to get the fifo issue
resolved. If this particular issue could be solved we'd have a real great network capable front-end for brutefir.
Cheers
I updated the brutefir setup Wiki with an "mpd-section".
The problem - if you start and stop mpd playback, mpd flushes the fifo which makes the brutefir daemon die, because it sees a bad file descriptor.
This needs to be solved on either of the ends. Either brutefir becomes immune against bad file-
descriptors on the fifo or MPD stops flushing the fifo on start and stop. phofman had an idea how to tackle this. I havn't really looked further into it.
The current workaround is to start playback before you start brutefir.
Once the playlist is playing in mpd next/prev/pause functions can be used without killing brutefir.
Let me know if the Wiki description works.
Would be great if some hackers around here can jump into this discussion to get the fifo issue
resolved. If this particular issue could be solved we'd have a real great network capable front-end for brutefir.
Cheers
Onvinyl said:
Well, the 'correct' way to integrate this is via Jack, which is designed from the ground up to be a low-latency interconnection mechanism between audio apps. The Jack infrastructure makes it pretty straightforward to route the output from one process into the input of another (assuming they support Jack of course) . This is the way I'm running, and it handles
mpd->brutefir->alsa output
I'll try to post the relevant snippets of my mpd and brute config files showing the setup of the jack ports. I think I even have a wrapper script that starts the whole thing up.
Not everyone uses Jack. soundchek for example I believe has decided that jack sounds bad in his setup and so doesn't use it. And, as you see over the last few posts, phofman has a legitmate point that Jack is a royal pain if you need to switch sample rates, and really doesn't add value unless you need to involve multiple programs in your playback.
In *my* opinion, I find messing around with shell scripts, fifos, pipes and .asoundrc hacks far less elegant and useful than simply using Jack, but then again we're not all necessarily aiming for the same goals.
BTW - mpd doesn't work out of the box with Jack2. the mpd jack output plugin defers the allocation of the ports and ringbuffers until after calling jack_client_activate, which sets up a race condition since Jack2 will apparently invoke the process callback any time after activate, causing a seg fault on the null pointer. Moving the port/buffer allocation up before the call to activate fixes it.
@dwk123
I think you're mixing things up here.
.asoundrc is needed if you want to go the multichannel route
via Alsa. This is very basic stuff - not even meant for hackers only.
fifos respectively pipes are a very basic thing though extremely valuable and powerful
within Linux. You can't live without them.
Doing some scripting is much better to get your own way of handling things
implemented. Sometimes we're talking about a small set of lines which make things
better or even manageable.
Of course we need clearly to distinguish between users and hackers here. These are completely different approaches. This discussion over here should not end up at Audio Asylum User level.
As an example - In your case you need to rely on libsamplerate.
We ( phofman and me) want it better -- by using Sox.
All applications incl. Jack are using libsamplerate. You need to live with the knowledge
that your conversions are not the best possible.
We just don't accept this. Fair enough.
Feel free to add your setup instructions to the Wiki. I'd really appreciate it.
Cheers
I think you're mixing things up here.
.asoundrc is needed if you want to go the multichannel route
via Alsa. This is very basic stuff - not even meant for hackers only.
fifos respectively pipes are a very basic thing though extremely valuable and powerful
within Linux. You can't live without them.
Doing some scripting is much better to get your own way of handling things
implemented. Sometimes we're talking about a small set of lines which make things
better or even manageable.
Of course we need clearly to distinguish between users and hackers here. These are completely different approaches. This discussion over here should not end up at Audio Asylum User level.
As an example - In your case you need to rely on libsamplerate.
We ( phofman and me) want it better -- by using Sox.
All applications incl. Jack are using libsamplerate. You need to live with the knowledge
that your conversions are not the best possible.
We just don't accept this. Fair enough.
Feel free to add your setup instructions to the Wiki. I'd really appreciate it.
Cheers
BTW, download source code of alsa-lib and alsa-plugins and search using cscope for methods convert and convert_s16. You will see that only the poor linear rate resampler offers the high-resolution convert, while all the other resampling plugins (resample, speex, lavc) offer 16-bit convert_s16 only. These resamplers are used e.g. in dmix, plug, rate plugins.
This is exactly the reason why I think a "piping" plugin allowing among other things quality resampling is useful.
It is important to distinguish between the low-level alsa infrastructure and the higher layers, e.g. jack. Using the piping plugin I should be able to upsample and/or transfer over network output of any alsa-aware application, incl. the jack chain. I have not tested all application cases though yet, some may not like the lack of regular timing of the sink.
This is exactly the reason why I think a "piping" plugin allowing among other things quality resampling is useful.
It is important to distinguish between the low-level alsa infrastructure and the higher layers, e.g. jack. Using the piping plugin I should be able to upsample and/or transfer over network output of any alsa-aware application, incl. the jack chain. I have not tested all application cases though yet, some may not like the lack of regular timing of the sink.
Perhaps slightly off topic, but worth mentioning for the ones searching for a cheap & small DIY linux audio sollution:
If you are not familiar with NSLU2: it is cheap (~$50 now) network device with two USB connectors, which can be hacked into a linux server.
Example pic
I just updated the debian on my NSLU2 and, to my amazement, it took me only 10 minutes to set up MPD on a fresh install of Debian 'lenny', since USB audio support is now working out of the box. And it works great! The people behind debian ARM and linux on the NSLU2 have done a amazing job on this one!
A few notes for archiving sake:
[1] Install Debian (lenny) on a Linksys NSLU2 (references: link link)
[2] Install the required packages as root:
and to get a /dev/dsp and /dev/mixer, do (references: link link link):
If you are not familiar with NSLU2: it is cheap (~$50 now) network device with two USB connectors, which can be hacked into a linux server.
Example pic
I just updated the debian on my NSLU2 and, to my amazement, it took me only 10 minutes to set up MPD on a fresh install of Debian 'lenny', since USB audio support is now working out of the box. And it works great! The people behind debian ARM and linux on the NSLU2 have done a amazing job on this one!
A few notes for archiving sake:
[1] Install Debian (lenny) on a Linksys NSLU2 (references: link link)
[2] Install the required packages as root:
Code:
apt-get install alsa-utils mpd mpc ncmpcand to get a /dev/dsp and /dev/mixer, do (references: link link link):
Code:
modprobe snd-pcm-oss
modprobe snd-mixer-ossECASX - The new Linux audio-player sound-quality reference
Hi folks.
I put some effort into writing a little player-script to utilize the recently discussed tools
sox, ecasound and flac.
It sounds IMO a lot better then any standard player you'll find under Linux.
You'll experience something like as if somebody has taken the towel away
from of your speakers.
This piece of software is really extremely easy to install.
Everybody can get it easily working, within two minutes.
Anybody interested to try the first drop ?
I called it ECASX.
It is a wrapper script which,
1. Plays .wav and .flac formats
2. Converts flac to wav offline
3. Converts 44.1 to whatever samplerate using the best SRC (170db SNR). It's done offline.
4. Plays entire directories or single files
5. 100% RAM playback
6. Looks like a little player with at least some formating
Note: It might be a good idea to have the Ubuntu rt-kernel installed. (Just one command!)
There is no better "upsampling" player on the planet I'd guess. This need to be confirmed
by some volunteers of course.
Anybody interested to give it a try? Drop me a PM.
Cheers
Klaus
Hi folks.
I put some effort into writing a little player-script to utilize the recently discussed tools
sox, ecasound and flac.
It sounds IMO a lot better then any standard player you'll find under Linux.
You'll experience something like as if somebody has taken the towel away
from of your speakers.
This piece of software is really extremely easy to install.
Everybody can get it easily working, within two minutes.
Anybody interested to try the first drop ?
I called it ECASX.
It is a wrapper script which,
1. Plays .wav and .flac formats
2. Converts flac to wav offline
3. Converts 44.1 to whatever samplerate using the best SRC (170db SNR). It's done offline.
4. Plays entire directories or single files
5. 100% RAM playback
6. Looks like a little player with at least some formating
Note: It might be a good idea to have the Ubuntu rt-kernel installed. (Just one command!)
There is no better "upsampling" player on the planet I'd guess. This need to be confirmed
by some volunteers of course.
Anybody interested to give it a try? Drop me a PM.
Cheers
Klaus
ackcheng said:
The SRC algorithm is the latest introduced by SOX. It outperforms Secret Rabbit Code, which
is used by the majority of applications via libsamplerate, by a large margin.
The basic setup is stereo only! The idea of the player is first of all to get rid of
the rather complicated setup of brutefir and getting very similar soundquality.
Of course one can easily build in the huge number of (multichannel) functions
of ecasound and Sox.
Cheers
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.