Opened 7 years ago

Closed 2 years ago

#3841 closed defect (fixed)

Playing some .wav files do not work

Reported by: humitos Owned by: humitos
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Jukebox Version: Unspecified
Severity: Unspecified Keywords: gtk2 13.1.0
Cc: humitos, godiard, jnettlet Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

Steps to reproduce:

  1. Download a .wav example
    wget http://marine.rutgers.edu/leophone/june_chorus.wav
    
  2. Open Jukebox
  3. Add the .wav file

Issue:

The sound is weird and has nothing to do with the real audio

Expected behaviour:

Play the audio as it is

Environment:

Jukebox gtk2 branch

NOTE: this[1] .wav file DO work

[1]

wget http://people.sc.fsu.edu/~jburkardt/data/wav/thermo.wav

Attachments (2)

gtk2.Jukebox-2.log (71.3 KB) - added by humitos 7 years ago.
gtk2.Jukebox-5.log (884.4 KB) - added by humitos 7 years ago.
Sometimes Jukebox crashes

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by humitos

Changed 7 years ago by humitos

Sometimes Jukebox crashes

comment:1 Changed 7 years ago by humitos

Sorry, this log file gtk2.Jukebox-5.log belongs to ticket #3843

comment:2 Changed 7 years ago by humitos

  • Component changed from untriaged to Jukebox
  • Owner set to kushal

comment:3 Changed 7 years ago by dsd

  • Keywords 13.1.0 added

comment:4 Changed 7 years ago by dsd

  • Owner changed from kushal to humitos
  • Status changed from new to assigned

comment:5 Changed 7 years ago by humitos

  • Cc jnettlet added

Chat with Jon:

(16:08:24) humitos: jnettlet: using this .wav file http://bugs.sugarlabs.org/ticket/3841 I have problems...
(16:08:42) humitos: it starts playing something weird and then, Jukebox crashes
(16:10:11) jnettlet: humitos: without looking in depth my guess is one of the waves is at a lower rate than 44100 or 48000 Hz this causing our audio driver to do stepping which sounds horrible
(16:10:36) humitos: jnettlet: ah... I didn't know that our audio driver has that limitation
(16:10:41) humitos: jnettlet: it's a good answer
(16:10:58) jnettlet: humitos: so if we have bad sounding audio that is the first thing to test.  I have some config changes around that do the sampling in software first that we need to implement
(16:11:24) humitos: jnettlet: $ file june_chorus.wav 
(16:11:24) humitos: june_chorus.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 24414 Hz
(16:11:33) humitos: jnettlet: that is the .wav that doesn't work
(16:11:35) jnettlet: yep that would do it
(16:11:58) humitos: jnettlet: but this one... DOES work
(16:12:00) humitos: $ file thermo.wav 
(16:12:00) humitos: thermo.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 11025 Hz
(16:12:49) jnettlet: well the 24414 is a really strange rate.  11025 at 8 bit we can mostly handle if the sound isn't too complex
(16:14:02) humitos: jnettlet: it doesn't seem to be complex... it's just a man voice :P
(16:14:20) ***humitos is wondering about the meaning of "complex"
(16:14:28) jnettlet: regardless CC me on the bug and I will dig up my .asoundrc that forces software resampling before sending it to the hardware.
(16:15:13) jnettlet: humitos: there is an open bug from Quanta about one sample in one of the activities that also sounds "strange" I bet it is the same problem.
(16:15:44) humitos: jnettlet: ok, so... is not a problem that I can attack and fix...
(16:17:35) jnettlet: humitos: you could alter the gstreamer pipeline to force the software resampling, but really I would prefer to do this as an alsa configuration change.  Have gstreamer do what it wants and alsa can resample with speex to something the hardware can deal with

comment:6 Changed 2 years ago by quozl

  • Resolution set to fixed
  • Status changed from assigned to closed

Tested, no problem found, closing.

Note: See TracTickets for help on using tickets.