1016->1050 upgrade breaks AC3/DTS pass-through

[infofarmer]

I have just updated from 4.0b1016 to 4.1b1050 and ac3/dts pass-through doesn't work anymore. Here's what mplayer says:

Code: Select all

[AO OSS] Can't set audio device /dev/dsp to ac3 output, trying s16le...
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
[format] Sample format big-endian AC3 not yet supported
[libaf] Reinitialization did not work, audio filter 'format' returned error code -2


I have a via8237 built-in sound:

Code: Select all

found-> vendor=0x1106, dev=0x3059, revid=0x60
        domain=0, bus=0, slot=17, func=5
        class=04-01-00, hdrtype=0x00, mfdev=0
        cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        intpin=c, irq=22
        powerspec 2  supports D0 D1 D2 D3  current D0
pci0:0:17:5: reprobing on driver added
oss_via823x0: [MPSAFE]
oss_via823x0: [ITHREAD]
oss_via823x0: <VIA VT8237> port 0xe000-0xe0ff irq 22 at device 17.5 on pci0


My OS is a recent build of FreeBSD 8-current.

Any ideas?

[cesium]

Try disabling vmix (by setting vmix0-enable to OFF in the mixer, or "vmix_disabled=1" in /usr/lib/oss/conf/osscore.conf and restarting OSS). Can you paste 'ossinfo -v3' and 'ossmix' output?

Another idea is to try getting the mercurial repository sources and backtracking in the revisions to see where it breaks.

[infofarmer]

"ossmix vmix0-enable OFF" did the trick, thanks! mplayer still blurts out the same messages, but both AC3 and DTS are passed through all right.

I'd call the problem resolved, but if you still want to have a look at the output requested, here it is for both versions: http://dh.cenkes.org/oss/

Thanks!

[cesium]

(I can see what's the issue here: older OSS versions expressed ability to have multiple sound client (using vmix) by splitting them to /dev/dspN where each client uses a different node, while 1050 uses a single /dev/dsp and clones it, so you only see a single engine when vmix is off. /dev/dsp was pure hw earlier, now we need to disable software conversions - if mplayer were to open with O_EXCL than disabling vmix wouldn't have had to be disabled) I wonder if setting vmix0-enable to ON in the mixer, and setting vmix0-channels to Multich will work? Alternatively, does setting vmix0-src to OFF while vmix is enabled work?

Btw, I find these "Unknown mixer extension type" messages to be rather weird since these types do exist in OSSv4's soundcard.h... If you can edit cmd/ossmix/ossmix.c to report which names trigger this, it would be nice (Alternately, it could be a compile issue, but I doubt it).

[infofarmer]

Neither vmix0-channels Multich nor vmix0-src OFF solve the problem if vmix is enabled.

I use the FreeBSD port, which may cause discrepancies.

Didn't spot any compile-time error messages. Can you tell me what to add to ossmix.c?

[cesium]

Well, the port Makefile seems fine... Try changing line 556 in ossmix.c to print extname member too. e.g.

Code: Select all

diff -r 734ef37d61ae cmd/ossmix/ossmix.c
--- a/cmd/ossmix/ossmix.c       Thu Dec 18 15:24:15 2008 +0200
+++ b/cmd/ossmix/ossmix.c       Mon Dec 22 21:30:26 2008 +0200
@@ -553,7 +553,7 @@
          break;

        default:
-         printf ("Unknown mixer extension type %d", thisrec->type);
+         printf ("Unknown mixer extension type %d (%s)", thisrec->type, thisrec->extname);
        }

       if ((thisrec->flags & MIXF_WRITEABLE) == 0) printf(" (Read-only)");

[infofarmer]

It turned out I had old oss* utils in /usr/bin, while the new ones were in /usr/local/bin. Once I removed the old ones, no "unknown" warnings were seen again.