Linux Audio the way to go!? - Page 62 - diyAudio
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 2nd October 2008, 12:13 PM   #611
diyAudio Member
 
Join Date: Dec 2003
Location: hong Kong
Send a message via ICQ to ackcheng
Does anyone knows if Ubuntu Studio load the whole OS into RAM before running it from there? Is it possible to do that. If this can achieved, we should be able to further reduce the I/O traffic of accessing the hard disk.

SpbLinux seems to be able to do that!
  Reply With Quote
Old 2nd October 2008, 12:37 PM   #612
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by .: ZMN :.
Out of curiosity...

Has anyone tried the latest pulseaudio (>= 0.9.11) with its "glitchfree" feature? It has not shown up stable in the distribution I use and it is supposed to be a big improvement in audio time scheduling.

Matth.
I have not tested the glitchfree version, nevertheless have followed the discussion of pulseaudio's author Lennart on alsa-devel mailing list. I think the glitchfree feature brings ability to fine-tune latency for each application separately as some require low latency while other enjoy the benefit of large buffers and lower CPU overhead.

In any case great kudos to Lennart for his incredible effort in bringing modern features to linux AND his relentless push for alsa API cleanup which is so desperately needed and apparently not easy to accomplish.
  Reply With Quote
Old 2nd October 2008, 01:37 PM   #613
diyAudio Member
 
Join Date: Dec 2004
Location: Glasgow
Quote:
Originally posted by ackcheng
Does anyone knows if Ubuntu Studio load the whole OS into RAM before running it from there? Is it possible to do that. If this can achieved, we should be able to further reduce the I/O traffic of accessing the hard disk.

SpbLinux seems to be able to do that!
I think I have mentioned this previously.

Puppy linux does this and is only 90mb in total. SPB linux doesn't really provide as flexible a platform, and the community of puppy linux is similar to that of ubuntu. Packages from the slackware repositories can be installed on puppy and it is only a few kernel revisions behind the bleeding edge - it is as flexible as a mini OS gets. It can easily run off a small cf disk in an ide adapter to eliminate internal hard drive noise. This is what I have at the moment with a fanless CPU and PSU. There is a guide to setting up a headless mpd / puppy linux machine at diy paradise.

I have tried puppy with low latency patches but it broke quite a few useful features. But I am happy with the performance without these.

I think it is the squashfs filesystem kernel patches used in these mini distros that allows them to run from ram. I would imagine that ubuntu studio is far too big to be run from ram on the average machine. However, an ubuntu server patched for low latency running mpd and brutefir and controled remotely could boot off a small flash drive and run comfortably in ram to avoid excess read/write of the flash media.
  Reply With Quote
Old 2nd October 2008, 02:13 PM   #614
diyAudio Member
 
Join Date: Sep 2005
Quote:
Originally posted by phofman

In any case great kudos to Lennart for his incredible effort in bringing modern features to linux AND his relentless push for alsa API cleanup which is so desperately needed and apparently not easy to accomplish.
Indeed! Massive kudos to Lennart and all others involved in improving the sound system on Linux.

Are you aware of any distribution that will incorporate the glitchfree part in their next upgrade/update? I use Ubuntu and from what I have read, the updated pulseaudio and the required ALSA API updates will not make it in to the next big upgrade (due this month).
  Reply With Quote
Old 2nd October 2008, 03:20 PM   #615
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by ackcheng
Does anyone knows if Ubuntu Studio load the whole OS into RAM before running it from there? Is it possible to do that. If this can achieved, we should be able to further reduce the I/O traffic of accessing the hard disk.

SpbLinux seems to be able to do that!
If by OS you mean the kernel, than yes, kernel code + loaded modules + its memory structures are always in RAM and cannot be swapped out. If you mean the whole root partition of Ubuntu Studio, it is not loaded in RAM disc by default.
  Reply With Quote
Old 2nd October 2008, 03:25 PM   #616
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by phofman


I have not tested the glitchfree version, nevertheless have followed the discussion of pulseaudio's author Lennart on alsa-devel mailing list. I think the glitchfree feature brings ability to fine-tune latency for each application separately as some require low latency while other enjoy the benefit of large buffers and lower CPU overhead.

In any case great kudos to Lennart for his incredible effort in bringing modern features to linux AND his relentless push for alsa API cleanup which is so desperately needed and apparently not easy to accomplish.

Quote:
Originally posted by rossco_50


I think I have mentioned this previously.

Puppy linux does this and is only 90mb in total. SPB linux doesn't really provide as flexible a platform, and the community of puppy linux is similar to that of ubuntu. Packages from the slackware repositories can be installed on puppy and it is only a few kernel revisions behind the bleeding edge - it is as flexible as a mini OS gets. It can easily run off a small cf disk in an ide adapter to eliminate internal hard drive noise. This is what I have at the moment with a fanless CPU and PSU. There is a guide to setting up a headless mpd / puppy linux machine at diy paradise.

I have tried puppy with low latency patches but it broke quite a few useful features. But I am happy with the performance without these.

I think it is the squashfs filesystem kernel patches used in these mini distros that allows them to run from ram. I would imagine that ubuntu studio is far too big to be run from ram on the average machine. However, an ubuntu server patched for low latency running mpd and brutefir and controled remotely could boot off a small flash drive and run comfortably in ram to avoid excess read/write of the flash media.
Meawhile I wonder why one should run the entire system from ram!?!

I just made mpd - one particular playlist-folder to be exact- run of shared memory by a start script.

A kind of hack but if works:

#!/bin/bash
#
# witten by soundcheck rev 0.1 09-16-2008
#
# This mpd script sets up mpd to play files from shared memory on the mpd-server
# There won't be any disc access while playing the selected directory back
# You need to prepare the environment first:
# 1. edit /etc/mpd.conf: All config files db_file/log_file/error_file/pid_file/state_file configs should point to /dev/shm/.mpd/xxxxxx
# 2. Install mpc: sudo apt-get install mpc
# 3. cp ~/.mpd/state ~/.mpd/state.default Note: If the file state is not empty run $mpc clear to generate a default state file.
# 4. cd <your_musicdir> && ln -s /dev/shm AAA
# 5. mv /usr/bin/mpd /usr/bin/mpd.bin
# 6. save this -script-file under /usr/bin/mpd as root (sudo) and $chmod 777 /usr/bin/mpd
#
# Start:
# mpd <your-album-dir>
# Now you'll find a playlist of you shared memory under folder AAA in e.g. Minion
#
# Note: You'll loose the state file and its content as soon as you restart mpd.


MUSICDIR=/home/klaus/music

case "$1" in
"") echo "----------------------------------------------"
echo "Please specify album-directory - run-command: mpd <album-dir-without-slashes and-path>"
echo "----------------------------------------------"
exit 1
;;
esac

[ ! -d "${1}" ] && echo -e "Cant' find specified album-directory. Please check name!" && exit 1

mpc stop
rm /dev/shm/*wav > /dev/null 2>&1

echo "Copy data to Ram!"
cp $1/*wav /dev/shm
cp /home/klaus/.mpd/state.default /home/klaus/.mpd/state
cp -rf /home/klaus/.mpd /dev/shm/.mpd
killall mpd.bin
chrt -f -p 10 /usr/bin/mpd.bin /etc/mpd.conf # this option works on real time kernels.
mpc update AAA
mpc ls | grep AAA | mpc add

exit 0

###End of Script
  Reply With Quote
Old 2nd October 2008, 03:32 PM   #617
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by anbello



Sorry, maybe i missed something but why don't use jackd as glue between MPD and brutefir?

ciao
andrea
Andrea.

Because it is just another layer in between. I assume many of the users will only play stereo data from one source via mpd towards brutefir via Alsa to mutiple outs. I think jack would be overkill in this application.

What would be the benefit to have Jack in there?

Cheers
Klaus
  Reply With Quote
Old 2nd October 2008, 03:56 PM   #618
diyAudio Member
 
Join Date: Dec 2004
Location: Glasgow
Quote:
Originally posted by soundcheck


Meawhile I wonder why one should run the entire system from ram!?!


I agree. No benefit for ubuntu on a higher spec machine, especially where there is no disc activity during playback.

But through puppy I have a very affordable and efficient system with no moving parts (except external usb drive) which I believe sounds good. It has more overhead than it would running ubuntu. I will be interested to see if mpd and the emu alsa drivers will ever support 24bit - my hardware may then be the limiting factor for high res files.
  Reply With Quote
Old 2nd October 2008, 04:39 PM   #619
diyAudio Member
 
Join Date: Dec 2003
Location: hong Kong
Send a message via ICQ to ackcheng
You mean puppy linux has even more overhead than Ubuntu?
  Reply With Quote
Old 2nd October 2008, 04:45 PM   #620
anbello is offline anbello  Italy
diyAudio Member
 
anbello's Avatar
 
Join Date: Sep 2004
Location: Italy
Quote:
Originally posted by soundcheck


Andrea.

Because it is just another layer in between. I assume many of the users will only play stereo data from one source via mpd towards brutefir via Alsa to mutiple outs. I think jack would be overkill in this application.

What would be the benefit to have Jack in there?

Cheers
Klaus

Yes it's another layer but with no negative effect for what i know and for what i hear in my sytem (MPD, brutefir with DRC fliter, jack, alsa, terratech aureon 7.1 space with envy24 chipset and wolfson dac).
Moreover it adds flexibilty to the system and it's very easy to use to connect application to each other and to sources and sinks.

ciao
andrea
  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 10:40 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