Opened 13 years ago
Last modified 7 years ago
#7863 assigned bug
[BSound] audio garbled, sometimes crashes, on files other than WAV
Reported by: | ttcoder | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Media Kit | Version: | R1/alpha3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
The playback is perfect for riff-wav files but is mostly gibberish on other file types. Playback quality improves when increasing buffer-size: it starts to ressemble the actual file at 8192 bytes (but really distorted, as if heavily downsampled to a more bass frequency), and becomes 95% free of pops and clicks at huge buffer sizes (e.g. 65536 bytes).
The key/odd thing to me is that WAV files work perfectly, the others do not.
Change History (8)
comment:2 by , 13 years ago
New data point: I get perfect playback of both mp3 and Wav files (well, 'perfect' provided there is little other CPU usage on the machine) if I forego use of class BSound and instead go with class BMediaFile, borrowing the code from Haiku's repository (class MediaFilePlayer).
(edit: this is nightly hrev42637 BTW)
comment:4 by , 10 years ago
No change: I'm not using class BSound (guessing it's not used much or at all for playing mp3s in the BeOS/Haiku world), and TT has been working very well on Haiku for years using BMediaFile
instead. Class BSound
could be marked as "deprecated/not-supported" in the BeBook I guess (maybe it's already so and I missed it). This ticket could be closed e.g. as will-not-fix.
comment:5 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|---|
Priority: | normal → low |
comment:6 by , 10 years ago
Milestone: | Unscheduled → R1 |
---|---|
Priority: | low → normal |
That you don't use it doesn't mean it's not part of the BeAPI anymore, and we have to support this properly even if there are other ways.
comment:7 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:8 by , 7 years ago
@ttcoder BSound uses BMediaFile in some way. It would have been a nice service to the community looking at this. My guess is that the problem is how BSoundPlayer uses it. I ran across this issue because I rewritten the Sound preflet to fix some bugs.
On the other hand there's also BSoundFile, one of the two should be deprecated.
Details --
File types:
Hardware:
this is with the Auich driver, but it behaved the same when I tested with the SB-Live/emuxki plugged-in.
Software:
this is Alpha3 (gotta try again on a nightly, though the nightly of 2 weeks ago was no better than R1A3).
Crash:
The crash I got a couple times after a few seconds of playback: in _SoundPlayBufferFunc/ GetDataAt/ ReadFrames
Stdout:
I've also noticed that the MediaKit "audio decode" warnings sent to stdout report some different offsets [from within MediaPlayer compared to from within TT]:
To wit:
Whereas TT results in this output:
So it looks like the MediaKit's underlying MP3 decoder "spreads thin" for me, making the audio sound more bass and 'chopped'.
Code:
Here's the code I use (which does work for WAV files, but not others):
Similar tickets: Found #7285 but my ticket is about garbled sound, whereas 7285 is about latency. There are some troubling similarities though.
I've also tried the sample code over at #4825 but it seems that this (closed) ticket should be re-opened: the sample code listed on that ticket results in some EXTREMELY loud garbled sound, and sometimes crashes -- i.e. that other code behaves even worse than mine.