BIT Linux 3.1 (1002), kubuntu 12.04, error 170: "Unsupported waveform audio..."

[mpesi]

Sorry I was out of the office yesterday.

"plughw" is the interface we use in BurnInTest when trying to access the sound hardware. You could also try speaker-test with "default" or "hw:0,0" to see if any of these will work.

Also is the user part of the "audio" group?

We'll see if we can setup a PXE boot system to try and reproduce it.

No problem.
Speaker-test works with default, but hw:0,0 gives same result as plughw.

The user is part of the audio group.

For your PXE environment, get Edubuntu - very fast to set up. That's what I'm using, and the basic environment was up and running in 10 minutes. Configuring BiT took a bit longer, as it has to be added to the image.

[Tim (PassMark)]

There is a way to change the device we use which you can try but currently only with the command line version.

If you open the cmdline_config.txt file and find the sound section you can add a "SoundDevName" parameter so you could could change it to something like this;

<Sound>
SoundDevName default
MaxDistortion 5
</Sound>

[Tim (PassMark)]

While doing some reading about it I came across this,

"ALSA itself does not support network operation, so an intermediary must be used." (https://wiki.ubuntu.com/ThinClientAudioSupport)

which is probably why it is working when you install it to disk but not when run across the network. It probably make it more difficult as we're trying to access the hardware at as low a level as possible.

I'll continue setting up the server to test it out but it looks like the sound test as it currently works may be simply unavailable in this situation.

After getting a edubuntu PXE/LPTS server (barely) running I had similar issues, i could run the test without any problem when logged into the server machine. However when running form a client machine (using the same login credentials used during the install process) I was getting corrupt audio input errors (so the input and output devices were able to be accessed but one or bother were not working as expected).

Given the way thin clients work is there really a reason you want to run BurnInTest like this? It may be a better idea running BurnInTest using a CD or USB self booting solution (http://www.passmark.com/support/bitl..._cd_slax.htm)?

[mpesi]

The command line test gave me the same error as the GUI, even with default specified as the audio device.

As for why we want to test this way, we have a few reasons:

1. Convenience - we have three manufacturing facilities, all of which will soon be on the same MAN. This server will then be able to support tests at all three facilities.

2. Maintenance - central control of our test setup. Changes are deployed more rapidly than if we have to create and deploy multiple thumb drives or CDs.

3. Limitations - for various reasons not all of our computing products have CD/DVD drives or USB ports.

[mpesi]

The command line test gave me the same error as the GUI, even with default specified as the audio device.

As for why we want to test this way, we have a few reasons:

1. Convenience - we have three manufacturing facilities, all of which will soon be on the same MAN. This server will then be able to support tests at all three facilities.

2. Maintenance - central control of our test setup. Changes are deployed more rapidly than if we have to create and deploy multiple thumb drives or CDs.

3. Limitations - for various reasons not all of our computing products have CD/DVD drives or USB ports.

And, booting across our network is a de facto NIC test - NIC malfunction = no boot.

[Tim (PassMark)]

After playing around with it here, I don't think we can support the sound test when running via PXE/LTSP at this stage. There is difficulty working with just the ALSA sound subsystem and it looks like it requires using some higher level functions from another sound API in order to get it to work.

[JimB]

I'm getting this same error using Wheezy (Debian) 64bit with a new AMD chipset SOC. It has several sound cards built in (HDMI etc).
speaker-test -c 2 -D plughw ;does NOT work
speaker-test -c 2 -D plughw:1 ;DOES work
speaker-test -c 2 -D default ;DOES work

Short of running in command line mode (which still didn't seem to work)
can there be a way to define the sound hardware that we want to test - either
command line option or better yet an option on the sound configuration page?

I would think going forward this will a common issue we will be seeing.

Thanks,

JimB

[Tim (PassMark)]

We'll look at adding a way to configure the sound device in use for the next release.

[JimB]

Any idea on when this may be available? I'd be willing to test it for you
tks

[JimB]

Just checking in to see if this is available now?

Thanks,

jb

[Tim (PassMark)]

No, there isn't a new release of BurnInTest with this change available yet.

[JimB]

I just downloaded and tried the latest version posted - release notes say the is a fix for this issue. I now see we can define the output device name but changing it still doesn't produce sound - same error reported. Is there something more that needs to be done? My post #22 still applies as to what works for speadker-test. Any help will be greatly appreciated.

Jim

I just rebooted and the sound now worked - sort of. I get some sounds but it appears to be in loop-back mode. Is there a way to just play sounds - like the older versions do? I do want loop-back mode eventually but I was hoping to just get a wav file playing for now. Thanks.

[Tim (PassMark)]

BurnInTest Linux only has the sound loopback test and not a playback test.