No sound (OSS) and Volume Control replicant inactive

[Pete]

On a ThinkPad 570E laptop running hrev30629, trying to play an MP3 through MediaPlayer produces no sound (though it appears to play and the VU meter is active). The Deskbar Volume Control is entirely red, and the knob remains at '38dB' (it can be moved, but always returns to that value). I've tried reloading OpenSound -- even recompiling from current sources -- with no effect.

Under an earlier revision (29462) sound works... sometimes. (I understand this is a known bug, though I can't find it in the Tracker.) The Volume slider works in this revision, though.

The sound chip appears to be a Crystal CS4614, reported (in Media Preferences) as "CS4280" in the working version, and "CS461x" in the one that doesn't.

[Pete]

Addendum: Realizing that there's an 'osstest' app, I tried that (after killing media_addon_server), and it generates good sound.

[stippi]

So what happens if you delete /boot/system/add-ons/kernel/drivers/bin/hda? Does OpenSound work then?

[Pete]

Nope -- removing hda (well actually renaming it and removing the link in .../multi) has no effect.

[umccullough]

I don't think renaming a driver doesn't prevent it from loading... it needs to be moved out of the drivers/bin I think?

[umccullough]

Let me try that again:

I don't think renaming a driver prevents it from loading...

[Pete]

Hmm. My understanding would be that the kernel scans the various '/boot/system/add-ons/kernel/drivers/dev/*' directories to link to actual drivers in '.../bin', so if the link doesn't exist, the add-on in bin isn't seen. In any case, I went back and moved the hda binary right off to a non-system folder in another partition. Same no-difference. (Rebooting included, of course...)

[korli]

Replying to umccullough:

Let me try that again:

I don't think renaming a driver prevents it from loading...

I usually move a driver to its parent directory to prevent it from loading.

[Pete]

Tracked it down [after a long and convoluted journey...(:-/] The 'volumeWhich' switch (in desklink state) was somehow set to VOLUME_USE_PHYS_OUTPUT, which apparently is not compatible with the Crystal chip and/or OSS. (How this happened I'm not clear, as it seemed to be that way from the moment I installed the rev.)

Finding the item in "Options" in the volume control menu and unsetting it fixed things, and sound works as it did before.

I see a series of checks in MixerControl::MixerControl(...) that try to handle the various card possibilities, but maybe it doesn't cover my machine. If it fails, though, the error seems to be 'PRINT'ed (to syslog?); maybe it should put a message right in the volume control or something.

[axeld]

Let's have François a look at OSS, and if that's solved okay there.

[mmu_man]

I added this code to desklink to optionally control the card's master volume instead, but there is no single way to identify this control in the parameterweb, so I had to try several matches from known drivers. The mixer code in the OSS node doesn't do much processing and publishes stuff almost as given by the driver from the ioctl.

[mmu_man]

Hi, do you still have the issue in a recent nightly with the 4.2_git-2 package?

You might want to check the Media Prefs for the default output, on my ASUS laptop I have to use the second (1) output instead of the first which is picked by default, else I don't get any sound. Change it and restart.