I suggesting leaving Pulse there. It's too difficult to remove given package dependencies, and it's unnecessary really. Also, with some fiddling it can even output to OSS4. You can then migrate programs slowly to OSS if you want to (you may have to edit MPD config files to make sure it chooses OSS output).

This has been a long time consuming venture to get bit perfect performance from Vortexbox.

Using the distro as supplied yields very "muddy" sound. In time I discovered that the cause was ALSA/Pulseaudio doing resampling and introducing digital volume controls. That was easily improved by sending data directly to SPDIF output with a HW setting.

SPDIF is the preferred output for my use since it supports 24/192 and sounds better than the other options.

Now I have gaps in playback between tracks and a split second of each track is clipped while the DAC relocks to each dropout between tracks. (This does not occur with USB, but that is limited to 24/96 and sounds worse than SPDIF)

I have just installed Squeezeslave to compare with MPD and I like it better so far.

What would I need to do to port Squeezeslave to OSS4? I am looking to bypass all processing and volume controls and have gapless playback.

Boy, is squeeze's buildsystem ugly (I can't see why they post patches separately and patch the source during build, which uses different patches depending on makefile used!). Per the wiki, the default build supports oss. If yours doesn't (maybe the distro messed this up?), rebuilding the source using makefile.linux26-display would give you oss support, but I didn't test this.

I was refering to Squeeze's sourcecode. No need to mess with OSS4 for this. I think Squeeze should already support oss - if the distro messed with it, you need to fetch Squeeze's source code and build it in - the Squeeze wiki page I mentioned has all the instructions for that.

cesium wrote:Boy, is squeeze's buildsystem ugly (I can't see why they post patches separately and patch the source during build, which uses different patches depending on makefile used!). Per the wiki, the default build supports oss. If yours doesn't (maybe the distro messed this up?), rebuilding the source using makefile.linux26-display would give you oss support, but I didn't test this.

Usually, such things can be easily installed on Arch Linux with one command.

## /etc/pacman.conf## See the pacman.conf(5) manpage for option and repository directives

## GENERAL OPTIONS#[options]# The following paths are commented out with their default values listed.# If you wish to use different paths, uncomment and update the paths.#RootDir = /#DBPath = /var/lib/pacman/#CacheDir = /var/cache/pacman/pkg/#LogFile = /var/log/pacman.logHoldPkg = pacman glibc# If upgrades are available for these packages they will be asked for firstSyncFirst = pacman#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u#XferCommand = /usr/bin/curl %u > %o#CleanMethod = KeepInstalled

## REPOSITORIES# - can be defined here or included from another file# - pacman will search repositories in the order defined here# - local/custom mirrors can be added here or in separate files# - repositories listed first will take precedence when packages# have identical names, regardless of version number# - URLs will have $repo replaced by the name of the current repo## Repository entries are of the format:# [repo-name]# Server = ServerName# Include = IncludePath## The header [repo-name] is crucial - it must be present and# uncommented to enable the repo.#

# The testing repositories are disabled by default. To enable, uncomment the# repo name header and Include lines. You can add preferred servers immediately# after the header, and they will be used before the default mirrors.

#[testing]## Add your preferred servers here, they will be used first#Include = /etc/pacman.d/mirrorlist

[core]# Add your preferred servers here, they will be used firstInclude = /etc/pacman.d/mirrorlist

[extra]# Add your preferred servers here, they will be used firstInclude = /etc/pacman.d/mirrorlist

#[community-testing]## Add your preferred servers here, they will be used first#Include = /etc/pacman.d/mirrorlist

[community]# Add your preferred servers here, they will be used firstInclude = /etc/pacman.d/mirrorlist

hifihere wrote:I have successfully installed the latest rpm for OSS4 from command line. When I startx to KDE GUI there is no evidence of OSS4. In multimedia settings the only option is Pulseaudio.

I have tried to install OSS4 again through the GUI by downloading the rpm. Now kpackagekit says I do not have the necessary privileges to install the rpm.

Still not able to use OSS4.

If you are not able to use OSS4 on your computer, there might be many different reasons for this:

1. OSS4 does not work with your soundcard.

2. OSS4 was not correctly installed.

3. Your KDE, or Gnome, or other apps, are configured for ALSA, and not for OSS4.

and so on.

Perhaps, it might be reasonable to test how OSS4 works with your hardware, before installing it in Fedora, SUSE, Ubuntu, or Arch.I tend to use Arch LiveCD for the purpose.Such tests can also be made with Ubuntu LiveCD, although, of course, it is a much more complicated procedure.

Reason number 3 applies to me for sure since ALSA/Pulseaudio are installed and working. How do I change to OSS4? I don't understand how it can report a successful installation at the finish of the command line operation and then be completely invisible for use.

hifihere wrote:Reason number 3 applies to me for sure since ALSA/Pulseaudio are installed and working. How do I change to OSS4? I don't understand how it can report a successful installation at the finish of the command line operation and then be completely invisible for use.

"How do I change to OSS4?" means that it is not yet installed. Right?Or it is installed and does not work?

Reason number 3 is that ALSA is still in charge and working. Even though OSS4 reports a successful installation at the end of the command line operation it is absolutely invisible to me for use in the GUI or through command line functions.

hifihere wrote:Reason number 3 is that ALSA is still in charge and working. Even though OSS4 reports a successful installation at the end of the command line operation it is absolutely invisible to me for use in the GUI or through command line functions.

I just read your other post about testing with a LiveCD running in RAM. Even if that works for me there is no promise that I will get ALSA removed from my Vortexbox/Fedora distro as easily as you did from the LiveCD build. I have already tried every ALSA removal command I could Google without success.

I guess I am accustomed to programs that say they are not compatible during installation or later. It does not seem probable that the installation went flawlessly and then the program is completely invisible, compatible or not.

hifihere wrote:I just read your other post about testing with a LiveCD running in RAM. Even if that works for me there is no promise that I will get ALSA removed from my Vortexbox/Fedora distro as easily as you did from the LiveCD build.

You are probably right. That is the reason why I am using Arch Linux now. Ubuntu became very difficult for me and time consuming.On Arch Linux, you do not need to remove things which you do not need, you simply do not install them.