No Audio output using LV8.6.1 on RHEL6 - 64 bit

[FSE-SAPHIR]

Hello everyone,

I am a colleague of SaphirMoutainClimber and we still have this problem.

I have repeated all the steps mentioned in the post but nothing work.

I am pretty sure that the problem is due to the fact that no /dev/dsp* file is present on disk.

So is there a way to force Alsa drivers to create this file and more generally, does somebody have feedback concerning the use of sound VIs under RHEL6?

Any help is welcome.

Florian

[AdamKemp]

I would start here: http://alsa.opensrc.org/OSS_emulation

[FSE-SAPHIR]

Thank you for your help.

I have tried to emulate OSS layer by loading snd-pcm-oss, snd-mixer-oss and snd-seq-oss like mentioned in your post.

First, I get an error due to snd-pcm-oss which was not available on disk.

So I have re-installed Alsa drivers and snd-pcm-oss is now available but we still have problems with LV.

More generally which sound modules or packages are necessary in order to make it work?

Does a such list exist?

[AdamKemp]

This is from the documentation of the sound API feature:

"(Linux) You must have the Open Sound System (OSS) driver to use the Sound VIs. LabVIEW searches for input and output devices by looking for files named /dev/dsp or /dev/dspX, where X is an integer between 0 and 16. LabVIEW attempts to open each input and output device. If LabVIEW cannot detect the sound card, check that a device file named /dev/dsp or /dev/dspX exists on the local system and that you have permission to read from and write to the device. If you moved this device to a location other than the default, LabVIEW can work with a symbolic link."

We do that searching when the sound API is first loaded into memory, and we don't requery after that. If you are experimenting with adding the sound device module while LabVIEW is open then you need to close all your VIs and then reopen them to verify whether it works in LabVIEW.

If you have a /dev/dsp device, but LabVIEW still can't use it then check permissions. See if you can open the device yourself (try "cat /dev/random > /dev/dsp" for some fun sounds).

[FSE-SAPHIR]

Thank you, I will investigate this way as soon as possible.

[metux]

*The reason we used OSS in the newer API is because at the time that we were porting this feature to Linux some of our officially supported distributions still did not ship with the ALSA driver. OSS was the only driver we could use that was guaranteed to be supported on each distribution at that time.

OSS is long obsolete since early 2k's. (IOW: at the time of you posting, it was about a decade).

There really was long enough time to spend a few hours for porting to ALSA.

<rant>It is unfortunate that Linux distributions routinely make changes like this which break third party applications. The result is that we just can't keep up with all the different ways that things can break in different Linux distributions, and unfortunately customers like you are stuck in the middle.

<RANT>

It's unfortunate that Billion-$ corporations like NI are so badly managed that they're completely incapable of maintaining their products over several years, ending up w/ lifetimes and quality below cheap China-ware. Even within a whole decade time you don't manage to invest a few hours to port some trivial call wrapper from OSS to ALSA. (a school kid could do that).

Oh, and we (the Linux community and distro maintainers) do NOT "regularily" break "third party applications" (= unmaintained proprietary code). It's the vendors who are lazier than a turtle and don't manage to get your stuff ported within a whole decade. NI doen't even get a simple CI set up (otherwise you wouldn't need the paying customers to tell you where your code breaks again, eg. the the ridiculous nikal).

We, the Linux community, ARE NOT responsible for keeping your proprietary stuff running. Our job is providing excellent OS quality, NOT playing the nanny for incompetent/unwilling billion-$ corporations ! (oh, and proprietary drivers are the exact opposite of quality).

If you ever find yourself asking why our support for Linux isn't better then this is the real reason.</rant>

No, the only reason is that this billion-$ corporation is completely unwilling to invest a few bucks in good GNU/Linux developers and open up the specs for their devices, so we can write drivers that are actually working. And in general, NI is completely unwilling to recognize how FOSS development communities are working, instead is really hostile to FOSS.

DO NOT blame us for your mistakes !