Opened 10 years ago

Last modified 4 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


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:1 by ttcoder, 10 years ago

Details --

File types:

  • WAV files are perfect, no flaw whatsoever that I can hear.
  • PCM files need a big buffer (though maybe a tad smaller than mp3s)
  • mp3 files need a big buffer.

this is with the Auich driver, but it behaved the same when I tested with the SB-Live/emuxki plugged-in.

this is Alpha3 (gotta try again on a nightly, though the nightly of 2 weeks ago was no better than R1A3).

The crash I got a couple times after a few seconds of playback: in _SoundPlayBufferFunc/ GetDataAt/ ReadFrames

Thread 2975 caused an exception: Segment violation
(gdb) bt
#0  0xffff012c in ?? ()
#1  0x00000000 in ?? ()
#2  0x00000400 in ?? ()
#3  0x00385849 in BPrivate::BTrackReader::ReadFrames ()
   from /boot/system/lib/
#4  0x00376775 in BSound::GetDataAt () from /boot/system/lib/
#5  0x00378745 in BSoundPlayer::_SoundPlayBufferFunc ()
   from /boot/system/lib/
#6  0x00379568 in BSoundPlayer::PlayBuffer () from /boot/system/lib/
#7  0x00389a31 in BPrivate::SoundPlayNode::FillNextBuffer ()
   from /boot/system/lib/
#8  0x003894f8 in BPrivate::SoundPlayNode::SendNewBuffer ()
   from /boot/system/lib/
#9  0x003893b5 in BPrivate::SoundPlayNode::HandleEvent ()
   from /boot/system/lib/
#10 0x0035cbf5 in BMediaEventLooper::DispatchEvent ()
   from /boot/system/lib/
#11 0x0035c894 in BMediaEventLooper::ControlLoop ()
   from /boot/system/lib/
#12 0x0035cc7f in BMediaEventLooper::_ControlThreadStart ()
   from /boot/system/lib/
#13 0x008ad7e6 in thread_entry () from /boot/system/lib/
#14 0x78247fec in ?? ()

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:

/tmp/> MediaPlayer 
open playlist item: Linkin Park - In The End.mp3
_InitFromTrack(): keyframes: 1, frame count: 9545356
running without video node
BMediaEventLooper: SchedulingLatency is 750
BMediaRoster::Connect connection established!
########### audio decode error, fChunkBufferSize 913, fChunkBufferOffset 0
AudioProducer::_FillNextBuffer() - supplier error -> silence
BMediaRoster::ReleaseNode, trying to release reference counting disabled timesource, node 2, port 3752069, team 1596

Whereas TT results in this output:

/tmp/> ./TuneTracker   # playing obviously the same mp3 as above, by the way
########### audio decode error, fChunkBufferSize 2338, fChunkBufferOffset 0
########### audio decode error, fChunkBufferSize 2338, fChunkBufferOffset 0
########### audio decode error, fChunkBufferSize 2338, fChunkBufferOffset 0
SoundPlayNode::SendNewBuffer, event scheduled much too late, lateness is 8290
SoundPlayNode::SendNewBuffer, event scheduled much too late, lateness is 8288
SoundPlayNode::SendNewBuffer, event scheduled much too late, lateness is 8354
BMediaRoster::ReleaseNode, trying to release reference counting disabled timesource, node 2, port 3752069, team 1575
PluginManager: Error, unloading PlugIn ffmpeg with usecount 2

So it looks like the MediaKit's underlying MP3 decoder "spreads thin" for me, making the audio sound more bass and 'chopped'.

Here's the code I use (which does work for WAV files, but not others):

			media_node audio_out = GetOrMakeMixerFor(...);

			BSound * sound = new BSound( &mp3_entry_ref );//passing 'preload=true' makes no difference..

			media_format fmt;
			*((media_raw_audio_format *)&fmt.u.raw_audio) = sound->Format();
// necessary under Haiku, but not in BeOS! And audio still not 100% ok:
fmt.u.raw_audio.buffer_size = 65536;//32768;//16384;//8192;

printf("---> frame_rate=%f channel_count=%ld format=%lu byte_order=%lu buffer_size=%ld\n", fmt.u.raw_audio.frame_rate, fmt.u.raw_audio.channel_count, fmt.u.raw_audio.format, fmt.u.raw_audio.byte_order, fmt.u.raw_audio.buffer_size);

			auditionSoundPlayer = new BSoundPlayer(
					"TT_audition" );
			auditionSoundPlayer->SetVolume( 1.0 );
			auditionSoundPlayer->StartPlaying( sound );

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.

Last edited 10 years ago by ttcoder (previous) (diff)

comment:2 by ttcoder, 10 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)

Last edited 10 years ago by ttcoder (previous) (diff)

comment:3 by waddlesplash, 7 years ago

Still an issue? If so, does that workaround still solve the problem?

comment:4 by ttcoder, 7 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 ttcoder, 7 years ago

Milestone: R1Unscheduled
Priority: normallow

comment:6 by pulkomandy, 7 years ago

Milestone: UnscheduledR1
Priority: lownormal

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 axeld, 4 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:8 by Barrett, 4 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.

Note: See TracTickets for help on using tickets.