Version: (using KDE KDE 3.2.2) Installed from: RedHat RPMs Ogg vorbis files play at faster speed than normal. The problem appears at least in amaroK and juk, so it's not related to any of them. However, in xmms they work just fine (using the arts output plugin) because it seems it doesn't use arts/kde for decoding. I've got KDE 3.2.2, installed with the official KDE's FC1 RPMs. I get no debug or error message. In KDE 3.2.0 the problem didn't appear. Can anyone confirm this bug please ?
Can you try manually setting the sample rate for your card in KControl -> Sound & Multimedia -> Sound System -> Hardware? (Many cards now use 48000 Hz and sometimes this isn't detected properly.)
Do also check what sample speed the ogg itself has.
Thanks for the replies and apologies for the time I took to answer, I'm having plenty of exams these days: Scott Wheeler: Which sample rate should I test ? I've tried 48000 Hz and nothing seems to change. BTW, I have a Via 8233a sound chipset, with the sound card built-in in the motherboard. Roger Larsson: Sorry, I have no idea about how to check the sample speed. Anyway, I can tell you that the ogg vorbis file have beeen created with "Sound Juicer 0.5.5". Please, either check a Sound Juicer ogg vorbis song yours, or explain me howto check that. Anyway, this is the info I have achieved to obtain: $ ogginfo '01 - The Prince.ogg' [...] Nominal bitrate: 192,003000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... ALBUM=The Heavy Heavy Hits ARTIST=Madness COMMENT=Extraído con Sound Juicer TITLE=The Prince TRACKNUM=1/23 TRACKNUMBER=1/23 Vorbis stream 1: Total data length: 4719833 bytes Playback length: 3m:19s Average bitrate: 189,095873 kbps
Check file properties->Meta Info . Sample Rate (last of Technical Details). But since the source probably is a CD it is most likely 44100 Hz (do also check the number of channels - I had problems with mono sound in other sample rates)
Roger Larsson: Thanks: You're right; it's at 44100 Hz and it has 2 channels! If you need more info, I can provide it. BTW, I'm searching find other ogg files with other sample spped/number of channels to see if they have the same speed problem.
Roger Larsson: which problems did you have ? Did you manage to fix them ?
It was for the 'ktuberling', we tried to add .ogg compressed files. But since it was speech only we tried with 8kHz, mono - it did not work at all... I made some patches to 'oggvorbis_artsplugin' to make it work - but that plugin should not be used... see bug 37251
Report the output of "artsd -l0" when playing a file that is played too fast. You have to kill the old artsd before starting a new (use "killall artsd").
*** Bug 93071 has been marked as a duplicate of this bug. ***
For me when playing OGG files (variable bitrate, encoded with "oggenc -q 5 ..." from KAudioCreator) some files play fine, others are like "damaged", like jumping CD. Playing the files with bad results in ogg123 from console or Alsaplayer reproduce the sound file as expected (without errors). When playing in Juk/Noatun/Kaboodle at multiple times some parts of the audio are repeated. Like: "Helllo Worrrld" where it should be "Hello World" Looks like when decoding the OGG the variable bit-rate is not correctly taken into consideration.
The most like cause for this bug is the lack of the akode plugin from kdemultimedia. Please install it.
The "akode" plugin is installed: bruno@linux / $ ls -l /usr/kde/3.3/lib/*akode* -rwxr-xr-x 1 root root 955 Dec 29 17:06 /usr/kde/3.3/lib/libakode.la -rwxr-xr-x 1 root root 1047 Dec 29 17:06 /usr/kde/3.3/lib/libakode_mpc_decoder.la -rwxr-xr-x 1 root root 53056 Dec 29 17:06 /usr/kde/3.3/lib/libakode_mpc_decoder.so -rwxr-xr-x 1 root root 1071 Dec 29 17:06 /usr/kde/3.3/lib/libakode_mpeg_decoder.la -rwxr-xr-x 1 root root 13092 Dec 29 17:06 /usr/kde/3.3/lib/libakode_mpeg_decoder.so lrwxrwxrwx 1 root root 17 Dec 29 17:06 /usr/kde/3.3/lib/libakode.so -> libakode.so.1.0.0 lrwxrwxrwx 1 root root 17 Dec 29 17:06 /usr/kde/3.3/lib/libakode.so.1 -> libakode.so.1.0.0 -rwxr-xr-x 1 root root 53600 Dec 29 17:06 /usr/kde/3.3/lib/libakode.so.1.0.0 -rwxr-xr-x 1 root root 1195 Dec 29 17:06 /usr/kde/3.3/lib/libakode_xiph_decoder.la -rwxr-xr-x 1 root root 31948 Dec 29 17:06 /usr/kde/3.3/lib/libakode_xiph_decoder.so -rwxr-xr-x 1 root root 1505 Dec 29 17:06 /usr/kde/3.3/lib/libarts_akode.la -rwxr-xr-x 1 root root 626176 Dec 29 17:06 /usr/kde/3.3/lib/libarts_akode.so
Cool there are then two things that needs to be checked. First of all the output of artsd in debug mode (killall artsd; artsd -l0). Then to try with artsd in different sample-rates (-r44100, -r48000). Hopefully we can then get an idea of what goes wrong.
I tried artsd with the following commandline: artsd -F 7 -S 2048 -a alsa -d -r 44100 -b 16 -s 30 -l0 Snip from log output: UnixManager: got notifyIO socketconnection created, fd = 12 search playobject, mimetype = audio/vorbis creating akodeXiphPlayObject to play file akode: opening /home/music/ogg/L'ostendaise.ogg akode: play AudioSubSystem::adjustDuplexBuffers(-5) AudioSubSystem::adjustDuplexBuffers(-7) AudioSubSystem::adjustDuplexBuffers(-6) AudioSubSystem::adjustDuplexBuffers(-5) The last lines (AudioSubSystem::...) repeat quite often with values ranging from -5 to -7 (44.1kHz) or -2 to -7 (48kHz) As audio-drivers I use Alsa with dmix (@48kHz) for my onboard Intel 82801DB-ICH4 (Realtek ALC202 rev 0), but this should no be an issue as "ogg123 -d alsa09" plays correctly. The bahavior of artsd is not 100% identical for each playback, sometimes repetition is more pronouced, sometimes less, or tends to be clicking-like.
Known problem with dmix. It thinks it can resample and accepts artsd's offer of 44100Hz. In truth dmix's resampling is really horrible. Just force artsd to use the same resampling rate as dmix(48000Hz). If you know where to do it, please file the bug against ALSA/dmix.
If artsd offers 44.1k anyhow, what is the -r option of artsd good for? The results are equivalently bad for "artsd -r 44100" and "artsd -r 48000". Native alsa audio applications (alsaplayer, "ogg123 -d alsa09") work fine My alsaconf: pcm.asymed { type asym playback.pcm "dmix" capture.pcm "dsnoop" } pcm.!default { type plug slave.pcm "asymed" }
artsd should respect the -r option, but you can see the used rate as one the first informations when running -l0. I am graping for straws, but try -Dasymed to make it use the device directly. I've once seen problems in fragment sizes, where dmix requires specific sizes. The direct ALSA programs wouldn't normally see resampling problems because they only have one level of configuration.
Still looks like problem with OGG format or internal buffering in Arts, as playing the same file through Juk and "ogg123 -d arts file.ogg" (artsd -F 7 -S 2048 -a alsa -d -r 48000 -b 16 -s 30 -l0) produces different results. Juk produces the distortions, ogg123 is clean.
There is no internal buffering in arts and the decoder is the official libvorbis library that all other players also use. The only thing that can go wrong here that doesn't go wrong with ogg123 is misinformation. Artsd relies on correct informations from ALSA, this is why I ask you to put more parameters on artsd until the problem goes away. We can then find out if artsd is misreading the information or ALSA is misinforming.
I compared playback of the same song, once .ogg version, once .wav version. (.ogg = `oggenc -q 5 .wav`) Playback for .wav version if fine (artsplay .wav), but .ogg version is distorded (artsplay .ogg) The result is the same for all 4 combinations: artsd -r 44100 -D default artsd -r 48000 -D default artsd -r 44100 -D asymed artsd -r 48000 -D asymed (common parameter for artsd: -F 7 -S 2048 -a alsa -d -b 16 -s 30 -l0) Please find the complete logfiles on here: http://homepages.internet.lu/BrunoP/artsd-ogg.tgz
Since you are talking about distortion and the original bug talked about too fast playback, I think they are separate issues. I would like to have a sample of one of the files that plays badly. Send it directly to me at kde@carewolf.com
A work-around for my distortion problem is to define buffer-size in Alsa's ~/.asoundrc for dmix and dsnooped which are a MULTIPLE of the FragmentCount * FragmentSize set for Artsd. (Shouldn't artsd handle that correctly, especially as this buffer information is dependent on the sample-rate!??) (note that artsd is not flexible to configure for buffer-size from KControlCenter, e.g. 10ms buffer can't be set exactly there! (needs to be 15*128 for 48kHz)). In addition, setting buffer-sizes for dmix and dsnoop that are different let artsd refuse to start with the following message: AudioSubSystem::handleIO: write failed len = 4096, can_write = 6000, errno = 17 (File exists)
Arts is no longer developed and has been unmaintained for quite some time - more than 2 years. With phonon as the replacement for arts in KDE4, we're closing out all the arts bugs in Bugzilla since there is no chance of them being fixed. Thanks