OSS playback via xine is broken.

[adamk]

Any application that uses the xine engine (totem-xine, amarok, for example) produces nothing short bursts of noise when trying to playback audio via /dev/dsp.

Here's an example of the problem:

http://68.32.29.130/through-oss.mp3

If I switch amarok to use arts for playback, it works fine:

http://68.32.29.130/through-arts.mp3

Here's my ossinfo:

Code: Select all

Version info: OSS 4.1 (b rc2/200811040041) (0x00040090)
Hg revision: changeset: 499:7656ac428350, tag: tip, date: Wed Oct 29 22:46:59 2008 +0200, summary: Added mixer support to oss_userdev driver and the udserver sample program
Platform: FreeBSD/i386 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #7: Mon Nov  3 18:50:07 EST 2008     root@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC (memory.visualtech.com)

Number of audio devices:        5
Number of audio engines:        5
Number of mixer devices:        1


Device objects
0: oss_sblive0 SB Live interrupts=74 (74)


Mixer devices
0: SB Live (EM28028) (Mixer 0 of device object 0)

Audio devices
SB Live main                      /dev/oss/oss_sblive0/pcm0  (device index 0)
SB Live front out                 /dev/oss/oss_sblive0/pcm1  (device index 1)
SB Live side out                  /dev/oss/oss_sblive0/pcm2  (device index 2)
SB Live center/lfe out            /dev/oss/oss_sblive0/pcm3  (device index 3)
SB Live 5.1 output device         /dev/oss/oss_sblive0/pcm4  (device index 4)


This happens with vmix explicitly disabled and with it enabled.

Adam

[cesium]

Does 'xine' program fail too? Also, please paste 'ossmix' output.

[adamk]

Yes, xine has the same problem as well.

ossmix:

Code: Select all

Selected mixer 0/SB Live (EM28028)
Known controls are:
line [<leftvol>:<rightvol>] (currently 32:32)
line.rec ON|OFF (currently ON)
mic <monovol> (currently 0)
mic.rec ON|OFF (currently OFF)
cd [<leftvol>:<rightvol>] (currently 75:75)
cd.rec ON|OFF (currently OFF)
igain [<leftvol>:<rightvol>] (currently 75:75)
aux1 [<leftvol>:<rightvol>] (currently 32:32)
aux1.rec ON|OFF (currently OFF)
phone [<leftvol>:<rightvol>] (currently 0:0)
phone.rec ON|OFF (currently OFF)
rear [<leftvol>:<rightvol>] (currently 75:75)
center [<leftvol>:<rightvol>] (currently 75:75)
autorese ON|OFF (currently ON)
spkmode <FRONT|SURR|FRONT+SURR|DISCRETE> (currently FRONT+SURR)
pcm.main <monovol> (currently 100)
pcm.front <monovol> (currently 100)
pcm.side <monovol> (currently 100)
pcm.c/l <monovol> (currently 100)
pcm5 [<leftvol>:<rightvol>] (currently 100:100)
vol [<leftvol>:<rightvol>] (currently 75:75)
equalizer.prescale <monovol> (currently 100)
equalizer.lo <monovol> (currently 128)
equalizer.mid <monovol> (currently 128)
equalizer.hi <monovol> (currently 128)
equalizer.xhi <monovol> (currently 128)
equalizer.bypass ON|OFF (currently OFF)
front.spdif <monovol> (currently 100)
front.digcd <monovol> (currently 100)
front.ac97 <monovol> (currently 0)
front.pcm <monovol> (currently 100)
front.aux <monovol> (currently 100)
front.vol [<leftvol>:<rightvol>] (currently 100:100)
surr.spdif <monovol> (currently 0)
surr.digcd <monovol> (currently 0)
surr.ac97 <monovol> (currently 0)
surr.pcm <monovol> (currently 100)
surr.aux <monovol> (currently 0)
surr.vol [<leftvol>:<rightvol>] (currently 100:100)
record.spdif <monovol> (currently 100)
record.digcd <monovol> (currently 100)
record.ac97 <monovol> (currently 100)
record.pcm <monovol> (currently 0)
record.aux <monovol> (currently 100)
record.vol [<leftvol>:<rightvol>] (currently 100:100)


[cesium]

Well, lets try and see how xine sets up the device:
'xine --verbose=3' etc. It should give some "audio_oss_out" "output sample rate" "fixing sound card drift" and other audio related lines. Please paste them (best to cut out all the "load_plugins" and video stuff though).

[adamk]

Code: Select all

Script started on Fri Nov 14 05:36:32 2008
[ adamk@memory - /usr/home/adamk ]: xine --verbose=3 Media/Audio/Songs/Bob\ Seger\ -\ Night\ Moves.mp3
This is xine (X11 gui) - a free video player v0.99.5.
(c) 2000-2007 The xine Team.
Built with xine library 1.1.15 (1.1.15)
Found xine library version: 1.1.15 (1.1.15).
video_out: thread created
audio_oss_out: Opening audio device...
audio_oss_out: audio.device.oss_device_name = auto, probing devs
audio_oss_out: using device >/dev/dsp<
audio_oss_out: using SNDCTL_DSP_GETODELAY
audio_oss_out: supported modes are mono stereo (a/52 pass-through not enabled in xine config)
audio_out: thread created
xine_stream_new
video_out: thread created
audio_out: thread created
xine_interface: unknown or deprecated stream param 10 set
xine_stream_new
xine_interface: unknown or deprecated stream param 10 set
xine_stream_new
xine_interface: unknown or deprecated stream param 10 set
video_out_xv: VO_PROP_ASPECT_RATIO(0)
gui_xine_open_and_play():
   mrl: 'Media/Audio/Songs/Bob Seger - Night Moves.mp3',
   sub 'NONE',
   start_pos 0, start_time 0, av_offset 0, spu_offset 0.
xine: found input plugin  : file input plugin
id3: ID3V2.3 tag
TEST mod decode
ebml: invalid master element
demux_dts: unsupported DTS stream type, or not a DTS stream
id3: ID3V2.3 tag
TEST mod decode
xine: found demuxer plugin: MPEG audio demux plugin
video discontinuity #1, type is 0, disc_off 0
waiting for audio discontinuity #1
demux_mpgaudio: loose mp3 sync at offset 0
audio discontinuity #1, type is 0, disc_off 0
id3: ID3V2.3 tag
waiting for in_discontinuity update #1
vpts adjusted with prebuffer to 30605
load_plugins: plugin mad will be used for audio streamtype 01.
av_offset=0 pts
spu_offset=0 pts
xine_play
video discontinuity #2, type is 2, disc_off 0
waiting for audio discontinuity #2
audio discontinuity #2, type is 2, disc_off 0
waiting for in_discontinuity update #2
play_internal ...done
audio_oss_out: ao_open rate=44100, mode=8, dev=/dev/dsp
audio_oss_out: audio rate : 44100 requested, 44100 provided by device
audio_oss_out: 2 channels output
output sample rate 44100
audio jump, diff=-5
video jump
audio_out: inserting 8403 0-frames to fill a gap of 17176 pts
audio_out: inserting 8382 0-frames to fill a gap of 17134 pts
audio_out: inserting 8378 0-frames to fill a gap of 17124 pts
audio_out: inserting 8373 0-frames to fill a gap of 17115 pts
audio_out: inserting 8369 0-frames to fill a gap of 17107 pts
audio_out: inserting 8365 0-frames to fill a gap of 17098 pts
audio_out: inserting 8360 0-frames to fill a gap of 17089 pts
audio_out: inserting 8356 0-frames to fill a gap of 17079 pts
audio_out: inserting 8351 0-frames to fill a gap of 17070 pts


I continue to get those "audio_out: inserting" lines till the song finishes.

Adam

[cesium]

If you change "audio.oss_sync_method" key in ~/.xine/config (try all values), does this make a meaningful difference in output?

[adamk]

I don't appear to have that key in my ~/.xine/config file:

http://pastebin.ca/1256089

[adamk]

Also, this does not appear to be driver specific as it happens with with oss_ich as well.

Adam

[cesium]

Well, that option definately exists: http://xinehq.de/index.php/faq

You should try the various settings of the configuration entry audio.oss_sync_method. The options getodelay and getoptr ask the driver and might therefore show the problem. But chances are that only one is broken and the other works, so you should try them both first, since they are the most accurate. The option probebuffer does not ask the driver directly but tries to determine the buffer length from outside. This should work with any driver and is the way to go, of the driver dependent methods fail. softsync is the least accurate and should be used only in emergency situations.

[adamk]

getoptr mostly works, but I still get quite a bit of skipping and stuttering, but not nearly as much. I'll try and grab another recording if I can't resolve this.

Adam

[adamk]

Unfortunately, this only seems to work for xine, and not other applications that use the xine engine, such as amarok and totem-xine. Does anyone know where this key can be configured for those applications?

Adam

[cesium]

Well, I'd like to find out which methods fail most badly, and how much of this problem (if any) is xine's bug rather than OSS's (so try probebuffer and softsync too). I suspect getodelay method fails the same way as in the attached mp3s?

[edit: I read that amarok uses ~/.kde/share/apps/amarok/xine-config file (via this). And totem-xine uses ~/.gnome2/totem_config (from this)]

[adamk]

getodelay and probebuffer fail in the same was as the demonstrated in the mp3.

getoptr and softsync are better, almost acceptable, until I grab the position slider and move the song 30 seconds forward. The song then starts playing faster and starts skipping If I let it play from start to finish without adjusting the position slider, I have no problems.

I'll try and grab a recording of what I'm talking about when I adjust the slider.

Adam

[adamk]

http://68.32.29.130/xine-getoptr.mp3
http://68.32.29.130/xine-softsync.mp3

This is after I jump ahead 30-50 seconds. The second mp3 is interesting in that you can actually here a slow down in speed from too-fast to normal around second 10.

Adam

[cesium]

Well, I notice that the (mostly?) driver independant methods fail too, so if you can see what happens when using the native FreeBSD sound system it'd be nice...