LynxTWO volume control

[cococr]

Hello,
Yesterday I installed a LynxTWO card into my system, and grabbed the latest OSS to use it. I had used the card in an older setup of OSS (3.99 I believe). With a tiny bit of work (it is REALLY easy to setup, thanks!), I had control over the card.

The one thing I haven't been able to find is how to control volume levels on the outputs. With the older version, I could do something like:

ossmix -d2 output.a1.-.vol 100
ossmix -d2 output.a2.-.vol 100

to change the volume. I don't see those controls in "ossmix -d2", and was wondering how I can control the volume now. Any help is appreciated.

Thanks in advance,
Ron

[igorzwx]

Hello,
Yesterday I installed a LynxTWO card into my system, and grabbed the latest OSS to use it. I had used the card in an older setup of OSS (3.99 I believe). With a tiny bit of work (it is REALLY easy to setup, thanks!), I had control over the card.

The one thing I haven't been able to find is how to control volume levels on the outputs. With the older version, I could do something like:

ossmix -d2 output.a1.-.vol 100
ossmix -d2 output.a2.-.vol 100

to change the volume. I don't see those controls in "ossmix -d2", and was wondering how I can control the volume now. Any help is appreciated.

Thanks in advance,
Ron

Could you post the output of these commands:

Code: Select all

$ ossmix -d2
$ ossmix -d2 | grep output.a

[cesium]

Please paste the output of 'ossmix -a' command. At a pinch, you could use vmix for this (vmix0-outvol etc.), but the mixer should have controls for the card volume.

[igorzwx]

Please paste the output of 'ossmix -a' command. At a pinch, you could use vmix for this (vmix0-outvol etc.), but the mixer should have controls for the card volume.

Hi Cesium!

Does this card have HW mixing with OSS4?
I need this information for Audacity Wiki.

It seems that all ancient soundcards have HW mixing with Linux drivers, but newer soundcards are not likely to have HW mixing with Linux drivers. Right?
It is, perhaps, suggested that one can use PulseAudio instead. Right?

[cococr]

I have attached both the output from ossmix -d2 and ossmix -a.

[igorzwx]

I have attached both the output from ossmix -d2 and ossmix -a.

I do not see any volume controls there.
But you seems to have vmix enabled. It can be used to control the volume of playback, as Cesium suggested.
vmix is a kind of PulseAudio with low quality resamplers.
You may try to enable "Production quality" resampler. It may sound better than "High"

vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|OFF> (currently Fast)

"Fast" resampler is the lowest qualiy (and buggy) linear resampler.

Today we are testing the Lynx Two sound card from the American company of Lynx Studio Technology. The distinguishing features of this solution are the reference quality of sound and an a high price ($1000 to $1200 depending on the modification). http://ixbtlabs.com/articles2/lynxtwo/

It might be reasonable to disable "vmix", of course.
You may try to disable vmix in OSS configs and set your LynxTwo as default soundcard.
Another options is to disable that other card in BIOS and reconfigure OSS with "sudo ossdetect -v".

[cesium]

Grr.. It seems to be a bug. Can you email 4front about it?

For now, you can use vmix, but you need to attach vmix to the Lynx first (see here - you don't need vmix_no_autoattach step, nor symlinking - just vmixctl command at some startup script) since it's not attached. Then vmix0-outvol can be used to control volume.

igorzwx - yea, this card has HW mixing. New (non-professional) cards don't have it. Then some mixing solution (vmix/pulse/etc.) has to be used.

[igorzwx]

Grr.. It seems to be a bug.

It might be a kind of Ubuntu bug. It makes sense to test it with Arch Linux LiveCD.

The previous version of OSS4 might be available here:

Code: Select all

pkgver=4.2_2004
http://www.4front-tech.com/developer/sources/stable/gpl/oss-v${pkgver/_*}-build${pkgver/*_}-src-gpl.tar.bz2

PKGBUILD (it is patched to enable "Production quality"):

Code: Select all

# $Id: PKGBUILD 36678 2011-01-05 23:16:19Z bluewind $
# Contributor: Paulo Matias <matiasΘarchlinux-br·org>
# Maintainer: Daniel J Griffiths <ghost1227@archlinux.us>

pkgname=oss
pkgver=4.2_2004
pkgrel=1
pkgdesc="Open Sound System UNIX audio architecture"
arch=('i686' 'x86_64')
url="http://developer.opensound.com/"
license=('GPL2')
depends=('gcc' 'make' 'kernel26-headers' 'module-init-tools' 'libtool' 'sed')
makedepends=('pkgconfig' 'gawk' 'gtk2' 'findutils')
optdepends=('gtk2: for graphical mixer (ossxmix)'
            'hal: for automatic USB audio configuration')
conflicts=('oss-linux' 'oss-linux-free' 'oss-testing' 'libflashsupport' 'libflashsupport-pulse' 'libflashsupport-oss')
replaces=('libflashsupport-oss')
install=oss.install
backup=('usr/lib/oss/soundon.user')
source=("http://www.4front-tech.com/developer/sources/stable/gpl/oss-v${pkgver/_*}-build${pkgver/*_}-src-gpl.tar.bz2"
   'oss.rm-init-scripts.patch' 'oss.rc' 'oss.soundon.patch')
md5sums=('256aba264d523fb8ee444aaacfb8d3da'
         'b9a380a0ac8896390d71ac13676f27e1'
         '8ca7cdf94c56ab02890eb4aba6a4995f'
         '65f07fe241bfbf912f76d8b6d8f276b5')

build() {
   _dir=oss-v${pkgver/_*}-build${pkgver/*_}-src-gpl
   cd ${srcdir}/${_dir}

   # Avoid these flags conflicting with OSS build system.
   unset CFLAGS
   unset LDFLAGS
   unset OSFLAGS
   unset LIBRARIES
   export NO_WARNING_CHECKS=yes

   # Compile libflashsupport.so only in packaging time, so we avoid
   # conflicts with other packages and ease package management.
   msg "Building libflashsupport.so."
   cd oss/lib
   gcc -shared -fPIC -O2 -Wall -Werror flashsupport.c -o libflashsupport.so

   msg "Preparing the build environment."
   cd ${srcdir}

   if [ ! -d build ]; then
      # Create build directory and configure
      mkdir build && cd build
      sed -i.bak -e 's/GRC_MAX_QUALITY=3/GRC_MAX_QUALITY=6/g' ${srcdir}/${_dir}/configure
      ${srcdir}/${_dir}/configure --enable-libsalsa=NO
   else
      # Change to existing build directory
      cd build
   fi

   msg "Building OSS."
   make build

   msg "Patching init scripts."
   cd ${srcdir}/build/prototype
   rm usr/lib/oss/etc/S89oss
   patch -b -p0 < ${srcdir}/oss.rm-init-scripts.patch
   patch -b -p0 < ${srcdir}/oss.soundon.patch

}

package() {
   _dir=oss-v${pkgver/_*}-build${pkgver/*_}-src-gpl
   cd ${srcdir}/${_dir}

   msg "Copying files."

   # Install libflashsupport.so
   install -Dm755 oss/lib/libflashsupport.so \
      ${pkgdir}/usr/lib/libflashsupport.so
   rm -f oss/lib/{flashsupport.c,libflashsupport.so}

   cd ${srcdir}/build/prototype
   cp -a * ${pkgdir}
   chmod -R a+r ${pkgdir} # All files can have read permission (FS#13815)
   find ${pkgdir} -type d -exec chmod a+x '{}' \; # Make namcap happy
   install -Dm755 ${srcdir}/oss.rc ${pkgdir}/etc/rc.d/oss
}

If the driver for LynxTwo is "closed source", you may ask OSS4 developers to compile an old version for you.

igorzwx - yea, this card has HW mixing. New (non-professional) cards don't have it. Then some mixing solution (vmix/pulse/etc.) has to be used.

Thanks! Actually, I need a list of soundcards which have HW mixing with OSS4.

If I am not mistaken, the general situation is about as follows:
1. New professional soundcards do not have Linux drivers.
2. Ancient soundcards (before 2000) have HW mixing with Linux drivers.
3. Newer souncards (from 2004) do not have HW mixing with Linux drivers.

AC'97 (short for Audio Codec '97) standard was created in 1997; soundcards: Intel ICH, ICH2, ICH3, ICH4 and the like http://en.wikipedia.org/wiki/AC'97
The Envy24 chipset was developed before 2000; soundcards: ICE1712 and the like http://en.wikipedia.org/wiki/VIA_Envy
LynxTwo was created before 2002.
All these cards should have HW mixing with ALSA drivers and OSS4 drivers. Right?
Although, LynxTwo may not have ALSA drivers.

Intel HDA standard was created in 2004 http://en.wikipedia.org/wiki/Intel_High ... tion_Audio
Such HDA soundcards (e.g. Intel HDA ICH7) are not likely to have HW mixing with Linux drivers. Right?

Code: Select all

    38 oss_envy24   pci1412,1712   Generic ENVY24 based device
    39 oss_envy24   pcs1412,d630   M Audio Delta 1010
    40 oss_envy24   pcs1412,d631   M Audio Delta DiO 2496
    41 oss_envy24   pcs1412,d632   M Audio Delta 66
    42 oss_envy24   pcs1412,d633   M Audio Delta 44
    43 oss_envy24   pcs1412,d634   M Audio Audiophile 2496
    44 oss_envy24   pcs1412,d635   M Audio Delta TDIF
    45 oss_envy24   pcs1412,d638   M Audio Delta 410
    46 oss_envy24   pcs1412,d63b   M Audio Delta 1010LT
    47 oss_envy24   pcs153b,1115   Terratec EWS88MT
    48 oss_envy24   pcs153b,112b   Terratec EWS88D
    49 oss_envy24   pcs153b,1130   Terratec EWX 24/96
    50 oss_envy24   pcs153b,1138   Terratec DMX 6Fire
    51 oss_envy24ht   pci1412,1724   Generic ENVY24HT based sound card
    52 oss_envy24ht   pcs1412,3630   M Audio Revolution 7.1
    53 oss_envy24ht   pcs1412,3631   M Audio Revolution 5.1
    54 oss_envy24ht   pcs1412,6321   M Audio Audiophile 192
    55 oss_envy24ht   pcs153b,1145   Terratec Aureon 7.1 Space
    56 oss_envy24ht   pcs153b,1147   Terratec Aureon 7.1 Sky
    57 oss_envy24ht   pcs153b,1149   Terratec PHASE 28
    58 oss_envy24ht   pcs153b,1153   Terratec Aureon 7.1 Universe
    59 oss_envy24ht   pcs3031,4553   Ego Systems Juli@ *BETA*
    60 oss_envy24ht   pcs4933,4553   Audiotrak Prodigy 7.1
    61 oss_envy24ht   pcs3137,4154   Audiotrak Prodigy HD2
    62 oss_envy24ht   pcs1412,2401   Audiotrak Prodigy HD2 Advance DE
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/file/3db750724c2d/devlists/Linux

Do these envy24 soundcards have HW mixing with OSS4 or not?
_________________________________________________________________________________________
EDIT:
If it is a kind of "esoteric secret", I may try to fill the vacuum of information with mythology:
1. Originaly, there were ancient OSS drivers for ancient soundcards. They supported HW mixing.
2. Then those ancient OSS drivers were ported to ALSA together with HW support. The result was very modern and very advanced ALSA drivers for ancient soundcards.
3. Then new soundcards (e.g. Intel HDA) came to exist. ALSA developers created a kind of "advanced drivers" for Intel HDA soundcards. These new "advanced drivers" do not support HW mixing, largely because, perhaps, ALSA developers do not know how to do this with ALSA.
4. Then "advanced drivers" for Intel HDA soundcards were ported to OSS4. As a result, "advanced" OSS4 drivers do not support HW mixing.
5. The ancient OSS drivers were ported to OSS4 together with HW support.
See also: http://insanecoding.blogspot.com/2009/0 ... sorry.html

Sound in Linux has an interesting history, and historically lacked sound mixing on hardware that was more software based than hardware.
Many sound servers were created to solve the mixing issue.
http://insanecoding.blogspot.com/2009/0 ... sorry.html

...some developers for some absurd reason decided they needed a whole new system and API to go with it. This is known as the Advanced Linux Sound Architecture or ALSA for short. This new API is huge, mostly undocumented, incredibly complicated and completely different than OSS. Which means various sound card drivers have to be rewritten for ALSA, and all applications have to be rewritten (or have more sound system support like SDL and libao) in order to use ALSA.
Other advantages of ALSA is that they included a software mixer (which doesn't always work). But as should be apparent, applications aren't magically overnight going to start switching over to ALSA. And as ALSA isn't portable, people who want to support BSD and Solaris will of course be using OSS. Meaning to support ALSA would mean needing to support OSS and ALSA. Since OSS exists on Linux, why even bother? Realizing this, the ALSA developers programmed OSS emulation into ALSA, so sane developers can just program for OSS. But the big embarrassment here for ALSA is that using ALSA via its OSS emulation is usually better than using ALSA directly...
But for some really stupid reason, ALSA's OSS emulation doesn't support mixing. Which in the end really defeats the purpose of ALSA in the first place. I also have two sound cards which work both under OSS and ALSA and find OSS to just work better. Even more shocking is that I found in cards that have hardware mixers installed, they don't seem to be used by ALSA's OSS emulation, leaving such users without mixing in OSS apps. However, for some reason, I'm seeing a lot of propaganda lately that I have to make all my new applications use ALSA and not OSS because OSS is deprecated... http://insanecoding.blogspot.com/2007/0 ... linux.html

To summarize: the "advanced" ALSA drivers for Intel HDA soundcards do not support HW mixing, and, therefore, there is a myth that Intel HDA soundcards do not have HW mixing. There is also the so-called "market theory of soundcards" which explains the absence of HW mixing in "non-professional" soundcards, such as Intel HDA. There is also a belief that Linux users can easily consume any "credible mythology". However, the number of "true believers" proved to be very small (about 0.5%) http://blogs.adobe.com/open/2011/06/foc ... lient.html