Go Back   Home > Forums > Source & Line > PC Based

PC Based Computer music servers, crossovers, and equalization

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 18th January 2009, 12:35 PM   #911
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: DUS
Did you check within Minion preferences if the fifo ouput is active? And everything else is turned off!
__________________
::: Squeezebox Touch Toolbox and more ::: by soundcheck
  Reply With Quote
Old 18th January 2009, 01:39 PM   #912
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Onvinyl,

may I suggest you do it differently? Instead of using a script with many functions right away, you should try the individal components separately first. Test MPD separately from brutefir - e.g. aplay accepts audio data (raw as well as wav) on stdin, as well as sox. Just

cat fifo | aplay -Dyourdevice -proper params

The same for brutefir, stream a wav file to the input fifo of brutefir.

cat file.wav > fifo

The beauty of this high-latency audio chain linked by pipes is exactly the independance of individual parts. Plus you will learn a lot about config options of the applications involved and get an insight to the overall function of any more comprehensive script. Vast majority of scripts do not check all possible failure conditions, and you may be wasting time on something simple.
  Reply With Quote
Old 18th January 2009, 01:57 PM   #913
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: DUS
Hi phofman.

I tried now several things.

sox raw-format > fifo, your
cat > fifo

it'll always break on the brutefir side due to bad file descriptor.

The only way I made brutefir working was by reading from a pipe as you've done with
aplay:

sox my.wav -r 44100 -b 16 -t raw - | brutefir -nodefault myconfig

the brutefir config says in this case for the input device

device: "file" {path: "/dev/stdin"; };

Somehow brutefir needs to get a routine to restart automatically if receiving some mess from the fifo.

Cheers
__________________
::: Squeezebox Touch Toolbox and more ::: by soundcheck
  Reply With Quote
Old 18th January 2009, 05:52 PM   #914
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Well, mine was just a general example. If brutefir cannot read from other fifo than stdin, then piping in shell is the only way. Still you should be able to cat the pre-stored file to stdin of brutefir by

mpd > some.wav


cat some.wav | brutefir.....

or the cleaner way I should but do not prefer:

brutefir < some.wav
  Reply With Quote
Old 18th January 2009, 06:02 PM   #915
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: DUS
Quote:
Originally posted by phofman


brutefir < some.wav

I tried this earlier. brutefir won't even start.
__________________
::: Squeezebox Touch Toolbox and more ::: by soundcheck
  Reply With Quote
Old 18th January 2009, 06:10 PM   #916
diyAudio Member
 
Onvinyl's Avatar
 
Join Date: Aug 2002
Location: Germany
Quote:
Originally posted by phofman
Plus you will learn a lot about config options of the applications involved and get an insight to the overall function of any more comprehensive script.

Yes, that's a good point. I'll try thoroughly and report back in a week or so. Thanks a lot so far, Klaus and phofman!

Rüdiger
__________________
"I can feel what's going on inside a piece of electronic equipment. I have a sense that I know what's going on inside the transistors." Robert Moog
  Reply With Quote
Old 18th January 2009, 07:58 PM   #917
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by soundcheck

I tried this earlier. brutefir won't even start.
It is equivalent to cat file | brutefir or piping the data from another process. Are you sure the input file had correct format? What did the logs report?
  Reply With Quote
Old 20th January 2009, 11:49 PM   #918
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
I finally got a usb soundcard and have played with it a bit.

I believe for latency-noncritical playback most work should be done by the HW itself, leaving minimum to the CPU. That means minimum IRQs, large buffers, applications waking up in long periods, processing large chunks of data at each run. I can set my PCI card down to mere 3 IRQs per second and 3 writes of aplay per second.

The USB audio subsystem can be set in a similar way.

Raising MAX_PACKS from 20 to 1000 in usbaudio.c gave me a headroom for playing with the nrpacks parameter of the snd-usb-audio module. This parameter says how many packets (i.e. blocks of audio data transfered to the card every 1ms) each URB contains. In the linux implementation of USB audio it means how many ms of audio the USB controller processes without any help from the CPU.

And indeed, by setting nrpacks to 20 (i.e. 20 ms of data), I get 50 IRQs per second. By setting nrpacks to 100, the USB controller throws only 10 IRQs per second.

There is another setting - the period time value in alsa applications. This tells how much data in microseconds the application transfers to the driver in one call, i.e. how often it calls the driver. For PCI cards this equals to the IRQ period. The USB stack uses double buffering and the period time and IRQ time are somewhat independent.

Actually the USB IRQ period is the approximately the minimum of nrpacks and period size. For large values (nrpacks > 100, period size over half second), a proper combination of nrpacks and period time must be chosen to avoid xruns.

I did a few tests on my weak home Duron 1GHz:

nrpacks=100, period time=2secs -> 10IRQs /second, aplay reads data and writes the to alsa-lib every 2 secs (confirmed by strace). Almost zero load on the player side, 10 IRQ / s is virtually nothing for the kernel.

nrpacks=1000 ms of audio data (maximum the USB controller supports), period time =2 secs -> flood of xruns

nrpacks=1000, period time =0.7 sec -> mere 3IRQs/s (!), aplay wakes up/reads/writes every 0.7s.

Since kernel-mode IRQ handlers have decent priority, it is better to optimize for minimum user-space application activity than for IRQs frequency. Therefore, I chose the largest working nrpacks for the largest period size available and did stress testing:

48kHz/16bits, largest period size is 2.7 second. Indeed, aplay reads from the file/writes to the driver every 2.7s only! The largest nrpacks for my setup without immediate xruns is 100, i.e. 10 USB IRQs per second.

Playing:
aplay -F10000000 -v -Dplughw:1 48-long.wav

I loaded the PC with a killer combination:

1. sudo nice -n -15 dd if=/dev/sda of=/dev/null bs=4096

results in constant disc activity, priority of -15 gives dd quite some drive. Still the PC is perfectly responsive, dd takes only 7% CPU, no xruns of course.

2. sudo nice -n -19 make -j 5 bzImage

Before running this command, I cautiously setup a break by running as root

echo "killall make" | at now +2 minutes

Still, it took the at daemon running at normal priority over 5 minutes to kill the numerous makes and bring my old PC to life again - even the mouse was basically frozen.

When run at the default USB setup (nrpacks = 8, period size 0.125s) the audio was being almost constantly interrupted by xruns.

However, during the 5 minutes of dd at priority -15 and the 5 makes at priority -19, the poor aplay at normal priority 0 with nrpacks=100 and period size 2.7s encountered only 4 xruns! Joining the club and raising aplay's priority to -19 got rid of the few xruns completely. Constantly busy HDD, load-frozen mouse, perfect sound, no xruns. All this on an ancient PC and a cheap USB sound card.

Now make your own opinion for USB playback - hassles with RT kernel, low-latency fight, loading to RAM to avoid drive latency, or large buffers, minimum sound application activity and minimum IRQs frequency.

Plus I do not believe anymore that USB audio is inherently more CPU demanding than PCI. No PCI card allows as large buffers, as little CPU activity, and therefore such playback reliability as a USB chain configured to the extreme.
  Reply With Quote
Old 21st January 2009, 07:00 AM   #919
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: DUS
Hi phofman.

The standard USB setup runs actually pretty stable in all the cases I and 10000s other people tried it ( at least under normal load conditions).

It also a well known fact in the Linux Audio world that setting nrpacks to 1, disabling dynamic bandwidth allocation on the kernel and also setting

Code:
snd_pcm_hw_constraint_minmax(runtime,SNDRV_PCM_HW_PARAM_PERIOD_TIME, 
				     1000 * MIN_PACKS_URB,
 				   
  /*(nrpacks * MAX_URBS) * 1000*/ UINT_MAX)
to very low values in usbaudio.c, improved USB performance - soundwise - .


So what's actually your message, I don't get your point.

Cheers
__________________
::: Squeezebox Touch Toolbox and more ::: by soundcheck
  Reply With Quote
Old 21st January 2009, 09:45 AM   #920
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by soundcheck
Hi phofman.

The standard USB setup runs actually pretty stable in all the cases I and 10000s other people tried it ( at least under normal load conditions).
Sure, I was testing abnormal load conditions, and found out USB audio can be set up to stay stable even in an immensely loaded system.

Quote:
Originally posted by soundcheck

It also a well known fact in the Linux Audio world that setting nrpacks to 1, disabling dynamic bandwidth allocation on the kernel and also setting

to very low values in usbaudio.c, improved USB performance - soundwise - .
All these modifications do is lowering the latency of the USB stack. There is absolutely no reason why forcing the USB controller throw interrupt every 1ms (direct result of nrpacks=1 - I checked that it results in 1000 IRQs per second), thus forcing the kernel to handle the interrupts, significantly raising the chances of xruns (keeping up with these stringent timing requirements reliably is very difficult) should improve the sound.

The latency issue is crucial for musicians, e.g. it makes a huge difference for the feel when playing MIDI keyboard. I can imagine they would call the immediate response an improvement in sound.

Quote:
Originally posted by soundcheck

So what's actually your message, I don't get your point.
Cheers
I am trying to show that even USB audio (and PCI as well) can be configured to be very robust (i.e. no xruns) without the real time/ramdisk etc. hassle for long-latency audiophile playback.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



New To Site? Need Help?

All times are GMT. The time now is 09:59 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2