WAV playback sounds distorted

Status
Not open for further replies.
Frank B.....
Thanks for your reply.....queries......
Did you delete all tags from the file ? The tags are stored in front of the sounddata...??????
Not sure what you mean by tags in front of sounddata.....I was using MP3 files stored on SD and trying to read as they are...

And, of course it helps do run the teensy with 120MHZ, and to use -O2 ????????
I just using setup in Teensy arduino IDE .... 96 MHZ. .....not sure what os -O2


Or you can store the MP3 (better is aac!) in the program-flash or serial-flash .... ?????
I dont have the option serial memory chip attached.....so I assume can only use program-flash
I assume that only means small files or snipits of files. I was trying to read the MP3 library....Does memory only keep a list of what to play and play from SD as it demands OR does the whole file need first stored in flash and then play from flash.

Regards my double start problem.......
Yes...I am testing playing in a loop as per the example sketch.....so I thought bounce would not be required.
Just simply.......
wav.play("A.WAV");
delay(100); // or whatever to let it play a few milliseconds
wav/play("B.WAV"); // attempt to play another file
delay(100); // let it play a while

etc.
Then the loop repeats..........

Your MP3 player example plays cleanly....and also tried MP3 playing in a loop similar to the wav example....output waveform is very good...
no 2 starts anywhere, but 60 seconds between end of last playing and start on next playing as recorded on the output sound.
Probably this may be 30 milli seconds to stop last play and 30 seconds to start next play and synch etc before output.
I can see the library files involved but not sure on the fine details and variables used to follow or debug except you can point me......

The 2 start play is only in the wav player not the MP3 play.... either would do me if I can get a reasonable clean and short stop/start between files....For playing very short sounds or chirps.

I will try the pause.......but looks like it re-starts from where it stopped.....can it go back to start each re-start....OR move to any position....Like a "seek" function

Thanks for your help
 
have you tried with play_sd_raw?

does the behaviour persist when starting the file by other means? (ie button or using elapsedMillis or what?)

as mentioned in the other thread about this, i can't seem to confirm this behaviour of play_sd_wav (ie, neither the reset thing nor any overlap between successive files.) (then again, my code looks rather different from the wavfileplayer example, though the differences don't seem significant. specifically, i don't have any delay() in there and use a modified "play" function using File::seek(); but it's the same thing otherwise).

looking at play_sd_wav it's not immediately apparent (to me at any rate) what might cause a reset after a few milliseconds. (actually, there is no way in the official audio library to move/set/reset the file position, and i don't see how your code might cause "play" to be called twice.)

you should be able to pinpoint/confirm that something actually *is* resetting by putting some Serial.println() at suitable locations into the update and/or consume functions.

you might start with looking at the file position. for instance: in AudioPlaySdWav::consume, where it says case STATE_DIRECT_16BIT_STEREO, add a line saying Serial.println(total_length - data_length); that should print the current position.
 
Ok..
1. Tags: MP3 Files can have tags (embedded pictures, information about the artist and so on.) Delete them with a tool like "MP3TAG" (use google). Otherwise the codec has to seek within the file. This takes time.
2. -O2 is a switch for the compiler (to generate faster code)...hmm..ok..better ignore it if you don't know about it.
3. flash: if you use aac, mono, and 64kbps, its far more than a few seconds. (try to create such a file and look at the filesize. the quality is ok.
4. Your loop: try something like (stop();play("xy.wav");delay()...)
5. the wavplayer works for me..no doublestarts... :) if you send me your complete project, includeing soundfiles, i can look at it. (can give you my email via private message)

Edit:
- try to increase the delay(100) to delay(1000). Do you still have the double-starts ?
- try to allocate more adioblocks (maybe 30, only for a test)
 
Last edited:
I will have to do a bit more checking.....
The MP3 files are ones created myself in Audacity.........plus the test one on this thread

Regards the wav playing
I tried with stop() and still same. Even the first file open after powerup has 2 starts.....so not related to last file closing etc.
I tried longer delays and still same
you say allocate more audioblocks......is this same as audio_blocks in the .ccp file....how do I do that.???

Just noticed something perculiar......Reset button
I normally just power OFF and ON again to rerun sketches...amd that works OK....power vis PC usb port
If I press the reset button on my teensy reset does not re-run the program or reboot except the Teensy Loader is open. Is this normal.??
If I power via a usb power unit that reset does not work.....it stops the prog running but does not reboot and run again until I power OFF and on again...
Probably not related to my wav playing problem but seems odd.
 
Also might be worth using AudioNoInterrupts and AudioInterrupts before and after (respectively) making any changes to any of the sound of objects. This might stop the audio library running away with itself reading partial bits from the SDCard while you are starting another sample?
 
Im glad we are having lots of discussion on this. But my issue is NOT related to MP3 or AAC or any other format but WAV. I have 50 kick drum samples. All in WAV format. They will be played in quick succession based on what the user does as a drummer. Think of it as a drum sample triggering system. When the samples are played slowly there is NO glitch. But as soon as the samples start being triggered in close succession to the previous , the glitches start appearing. Almost as if they are building upon the one before it. As I have mentioned in earlier posts, I have reformatted cards, copied files as a group and tried different card types. All with the same issue. I have increased audio memory. I have ran through a mixer with lots of different gain diminishing settings. I have modified line-out level settings. I have modified the audio samples and lowered the gain of the actual recordings. The glitches remain.

This glitch is most notable with kick samples as the low frequency of the kick in relation to the higher frequency of the glitch sound make it much easier to hear. That being said, the glitch does appear in all my other samples as well when triggered in quick succession. I would try the MP3 route, but even 30ms delay in access is to long. And as I stated earlier, I never noticed this glitch until I updated to the latest audio board and teensy software. I have been testing with these samples for over 4 months. And have recently noticed the glitching.

Im sure its something simple and overlooked. I appreciate all the ideas and input in this subject and look forward to figuring this out.
 
Pensive.....I have tried AudioInterrupts and AudioNoInterrupts and double starts remain...doesn't matter.

I see there is a seek function in the wav library....does it work....I will try that....

dsparks....we both have that same type of problem wnating to play short quick sounds....thats why I am interested

Thanks for your help
 
I know that it does not solve the "wav" problem, but for your kind of usage "raw" is clearly better, because there is no big header which must be read every time.
WAV/MP3/AAC are the wrong formats for both of you, i think. Too much overhead.
 
Frank B,

I dont have a delayed start or timing issue with WAV. Its very quick and the latency is not even noticed. Is there a way to know the file length of a RAW audio sample though?
 
Oh, and what specific formatting is needed for a RAW file to play on the audio board / teensy?

Signed 16bit PCM, uLaw, 16bit DWVW, etc?
 
Why don't you look at the simple code ? :)

play_sd_raw.cpp

Code:
bool AudioPlaySdRaw::play(const char *filename)
{
	stop();
	AudioStartUsingSPI();
	__disable_irq();
	rawfile = SD.open(filename);
	__enable_irq();
	if (!rawfile) {
		//Serial.println("unable to open file");
		return false;
	}
	file_size = rawfile.size();
	file_offset = 0;
	//Serial.println("able to open file");
	playing = true;
	return true;
}

It takes the filesize as length.
The format seems to be 16 bit mono, 44.1 khz (Paul, correct me if i'm wrong)
 
Out of curiosity:

What do your sketches do, if the WAV is not played until its end and a new one is to be played ?
Do you call stop(); ? Or do you just call play() again ?
Correct me, but would'nt it be better (and sound better) in this case to let it play to the end and use an additional player-object for the new wav ? (Polyphonic, even it is the same file)
Or, are you going this way already ?
 
Frank,

Initially the file is triggered by the user in whatever pattern they choose. The software checks to see if the sample is being played when another is triggered. And if the sample is playing already, will call stop() before playing the sample again. I tried implementing a 4 voice polyphonic setup but to no avail. It still had the glitching in it. And in fact was causing some latency issues as well.
 
When the samples are played slowly there is NO glitch. But as soon as the samples start being triggered in close succession to the previous , the glitches start appearing. Almost as if they are building upon the one before it. [...] This glitch is most notable with kick samples as the low frequency of the kick in relation to the higher frequency of the glitch sound make it much easier to hear.

so are we talking about the same glitch (re-triggering) or two different phenomena? incidentally, the latency-comparison I posted in the other thread is four bass-drum samples. they were triggered with a LFO, that can happen much quicker than any human drumming. (incidentally, too, though i don't think that's the reason i can't see/hear any glitches (i can't try atm), it's done the way Frank suggests above, by alternating two instances of AudioPlaySdWav for the same sample.)

(also i should add: that's with 1.0.6 and teensyduino 1.20. and there's only two monophonic channels involved (left and right), ie not lots of samples mixed down to stereo.)

I see there is a seek function in the wav library....does it work....I will try that....

where can you see that? there's none, AFAIK. (there's one in SD/File.cpp).

i only brought it up because of the apparent re-triggering. within play_sd_wav, there's no way to access the "playhead", that's all internal to the underlying SD stuff. so the only way the file could be reset to the initial position is by opening the file again, but that happens in AudioPlaySdWav :: play(), which is certain to be only called once (as far as i can see).
 
Last edited:
I just tried the 40bpx.wav from this thread.
There's a "click" at the end, when i play it. Is this meant ?
Code:
void loop() {
delay(2000);
wav.play("40BPX.WAV");
delay (200);
wav.stop();
}
With the stop(), the "click" is still present.

When i remove the stop, and do a delay(100);wav.play("40BPX.WAV"); i can't hear clicks.
With delay(80);wav.play("40BPX.WAV"); they are very loud.

Code:
void loop() {
delay(100);
wav.play("40BPX.WAV");
}

Is this the phenomen ? I ask to be sure.


Edit:
Funny, i just converted the file to mono, and with the delay(2000) the click is away.
With delay(100) it's existent.

Ok, this could be a sign, that something with the audiobuffers in the waveplayer is wrong..
 
Last edited:
The "click" is not the issue.

The quantization or bit crushing sound when played in quick succession is the issue. Listen to the recording I attached in the forum.
 
I can't hear anything like this.
Latest version Teensyduino 121#2

Maybe something with your electrical setup ? A ground loop ?
 
Reply to dsparks......
dsparks wrote......
"I dont have a delayed start or timing issue with WAV. Its very quick and the latency is not even noticed."

You posted your original 40BPX.WAV yesterday and later posted the recording of it played by Teensy.

When I looked at these in Audacity and compared the original with the recorded output I can see there is latency and the file has 2 peaks at the start showing the start appearing twice in the output. I posted .jpg of this on this thread. You may not hear it because it happens so quick and also the "crashing" sound of the drum. But it is there and this is what I am finding with my wav files. We may perceive it differently but I think it is the same problem. You also had a problem that all of the waveform was badly distorted or clipped. In my case only the start is distorted by the double starts and I can hear a click at start, the rest of the waveform is OK and not distorted. The recording comes out inverted for some reason. Hope this clears the ambiguity. I would like to play either wav or mp3 for my project rather than other methods so users can change sounds by simply copying different files to the SD.
 
Teenfor3,

Thats correct! The sound is there, but not noticeable until the sample is played in quick succession. More than 4/sec will give a good bit crushing sound if you listen well.
 
Ok.. last try :)

Is there the same effect when you convert the audio to raw and play it with the play_sd_raw ?
Please check this..

If no, we know exactly, that sd-wav has a problem.
If yes, the problem is not sd-wav related.
 
Frank,


YES the problem still occurs with the RAW file. I hope that helps. I know its not easy finding solutions when you cant reproduce the errors.
 
Yes that helps.
We don't need to search a bug in play_sd_wav. right ?
Or, raw has the same bug.

the only other audio-object is the i2s-output. right ?
 
Frank
I thought I would try your suggestion about playing mono to see what happened.
So I cleared my SDcard and formatted again using sdformatter
and copied one only mono.wav file to the SD and played it in Teensy.
It played perfectly, no 2 starts and almost no gaps between last file stopping and next file playing.

I recorded in Audacity 7 seconds of 100 ms of the file playing in a loop and only had 1 gap of 3 ms. All other joins were perfect waveforms
I had a faded start to the file so could easily see there was no double start.

I am now retracing my steps to play various stereo etc and see what happens. It seems it still must be the problems of needing a contiguous freshly formatted SDcard. Although I had never edited any of the files I had on the SD
 

Attachments

  • 7secs100ms.zip
    111.2 KB · Views: 107
Last edited:
so, it's both raw and wav now? but not mono?

not sure whether that's still at issue at this point but fwiw: looking again at the screenshots that were posted, it almost seems as if the first "attempt" lasts for exactly 2.9ms or 128 samples:


Screen Shot 2015-01-11 at 21.34.45.jpg

the others are too blurred to tell. but i guess that might indicate the first time the buffer is filled, for some reason it's played twice. (?)
 
Status
Not open for further replies.
Back
Top