Opened 11 years ago
Closed 6 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:
- Download a .wav example
wget http://marine.rutgers.edu/leophone/june_chorus.wav
- Open Jukebox
- 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)
Change History (8)
Changed 11 years ago by humitos
Changed 11 years ago by humitos
comment:1 Changed 11 years ago by humitos
Sorry, this log file gtk2.Jukebox-5.log belongs to ticket #3843
comment:2 Changed 11 years ago by humitos
- Component changed from untriaged to Jukebox
- Owner set to kushal
comment:3 Changed 11 years ago by dsd
- Keywords 13.1.0 added
comment:4 Changed 11 years ago by dsd
- Owner changed from kushal to humitos
- Status changed from new to assigned
comment:5 Changed 11 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 6 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.
Sometimes Jukebox crashes