Hello: new to the forum and stumped on an issue:

I'm attempting to deploy a thinclient image to 300 users. It's Thinstation. I'm aware that you may not know thinstation. This post is more about an odd event happening on several pc's using an image that I have working. Hardware: all Dell 760's. Audio applications that have been added to my image for Vmware audio and webcam: v4l-utils, alsa, alsa-lib, alsa-plugins, pulseaudio, gstreamer, and pavucontrol.

My image doesn't have volume control on the start menu, but does have a Master Volume next to the clock. I've deployed to about 10 users to test for me. Here's the audio issue:

One pc has full audio control and can change the volume on the linux toolbar if desired. Another pc has NO master volume control. Both are on same switch. So, I pulled back the non-working pc and put my working test pc in it's place. The test pc no longer has master volume control and the non-working pc now has the master volume control. Only change: Swapped pc's. This issue is effecting about 4 users at the moment and has stopped my deployment.

Any ideas?

I think better details will be helpful here as well as better organization. Rather than swap out PCs with the good intentions to aid a user, it might be best to thoroughly test the deployed solution and determine if there are potential issues which any given user can run into if they attempt to manipulate their personal settings, their desktop, or other things like install/uninstall certain other software packages.

For instance it might be interesting to know if a particular user is causing all of these problems because the first actions they may be doing is trying to over-customize a system once they get it.

It also will be helpful to inform us about the Linux distribution and version which you are using.

Saying that they are on the same switch seems irrelevant, you mean network switch? That has absolutely nothing to do with audio properties or their controls.

Diagnose one PC at a time. Interview the tester to find out if they installed any additional software packages. There are some ways I believe to tell this also, but that is beyond my knowledge, I'm not a Linux admin type.

I'd verify that the PC was still capable of sound and sound controls for instance using ALSA utilities or the available Linux device managers. Once again, Linux distro here is helpful.

This may be a simple case where the user removed the desktop interface to control sound and you need to add it back in, and then figure a way to avoid that happening in the future.

Finally, this is all assuming that you are talking "Desktop stand-alone" behavior. Or does this Thinstation come into play for audio, where what you're really saying is when running that client, things are not working properly?

rtmistler, Sorry for the somewhat vague intro. Didn't really want to write a disortation. And, I had to submit twice. It appeared the linuxquestions website either kicked me out of my original post or, more likely, I wasn't properly logged in to website ( I had to submit this twice). Until last May, I was not using Unix/Linux environment for most of a decade.

Linux Kernel and version: 4.6.3TS_SMP (32bit) #1 -- waiting for the 64bit stable release
Thinstation 5.5
sda1 partition is 1GB
Thinstation image is 270mb (approx.)

Users don't have any ability other powering on/off system, starting VMware to start their work, and volume control. We pxe-boot to the server to convert the pc to pull the image that will reside on the hard drive. The pxe-boot formats the local drive, downloads a tar.xz file and extracts to the hard drive. Once complete, system reboots itself and users can log in to Vmware after this. Other than telling the user to boot from network controller and choose option 1 for TS install, everything else is automated. And, they only pxe-boot once during the change-over. After that, they boot to hard drive. Only one user did the conversion on his own with instructions I wrote. I've sat with everyone else. We are converting from another brand of thinclient so the audio was working until conversion.

The audio issue starts after the pc is restaged to thinstation. And, every time afterward. But, only on some systems. If the volume control is not available, a skinny bar appears in its place (about 1/8" wide). Not a good description, but it appears that the application is there, just not available, stopped loading, or failed. If the audio is working, it only works for VMware. We designed it to pass the volume to the VMware session and don't use it in Linux.

Some of the systems have a different bios #, but that issue got thrown out when "what I thought was the good bios" got the same problem (Bios version A02). In thinstation, one of the early steps is to run a hwlister.sh that creates two files to build the hardware image from it (module.list, package.list). I found out later that a few system boards were replaced. So, I created it's hardware files. Since then, I've created the image based on the other system that had no audio-it didn't matter. I've merged files-didn't matter (don't know if I did it right, but any driver that wasn't in one file, I put in the other). I created two Dell760 hardware profiles and had both in the image-it didn't matter. And, both new and old bios' for Dell 760 have the same issue: Bios A02 and A16.

The pc swap was after a week of altering code a couple and redeploying the image after each change. That being said, the only reason why I swapped pc's was so I could work on the pc next to my desk rather than walking across the building to it. And, I agree that the network should have no bearing on audio. I'm just putting it in the notes because that's really the only change where the audio did or didn't work after the pc swap. "Move a pc to a different desk and the image works properly." Go ahead and say "Whaaaaat?!!!"

I'm wondering if the application is failing at boot and disabling the functionality. I think pavucontrol is the application that put the volume control on the task bar, but I don't remember exactly. If you could provide some direction in which audio application could put a "partial" volume contol icon on the taskbar but not complete it's config or allow audio after reaching the desktop, that'd be great.

Machines have multiple soundcards these days. Soundcard, webcam, and video cards are common audio inputs and/or outputs. The device that gets index 0 is the default.

$ cat /proc/asound/cards

You probably need to re-index the modules to load in a particular order so it gets 0 (/etc/modporbe.d/alsa???.conf), or you need to configure each as you set them up(~/.asoundrc). With pulseaudio you basically run pavucontrol and disable all the devices you DO NOT want to use.

$ pavucontrol

But there's many ways to setup audio in linux. Like alsa, jackd, pulseaudio, and many others over the generations. Each with their quirks.

1 members found this post helpful.

Shadow 7, thank you. $cat /proc/asound/cards showed that my system had 2 cards. Webcam on card 0 and Intel HDA on Card 1. When I pulled the webcam from my system and rebooted. My pc is now like all other users with issue. Would correcting the module.list order resolve this? Also, I ran the $pavucontrol command and I got a "Fatal Error: Unable to connect to PulseAudio: OK"..

The error that posted in the terminal window after the popup error: (pavucontrol:22447): Gtk-CRITICAL **:IA__gtk_main_quit: assertion 'main_loops != NULL' failed

You have to be using pulseaudio to run pavucontrol. Perhaps you are not running that. You can force index numbers by configuration to ensure that your onboard audio gets index 0. You can override the default in a custom .asoundrc. But still hit and miss as reboots can change the sequence and using the same install on multiple devices has different configurations. Most times I use the lazy .asound route.

FILE: ~/.asoundrc
You can beef that up with defaults.ctl.card and defaults.pcm.device. But that one line is the only one you "need" to have output go to the desired non-0 index. Unless you're using other sound daemons like pulseaudio or jackd.

1 members found this post helpful.