WAV playback sounds distorted

Status
Not open for further replies.
mxxx & Frank

I am now attaching the same loop play as last post but this time stereo. 11 seconds recorded with 100ms loop.....
wav.play(B.WAV);
delay(100);
wav.play(C.WAV);
delay(100);
You can see the waveform plays perfectly but there is now a clear double attempt to start to play each time. And it plays approx 3 ms of the file, then starts again and plays correctly this time. All I have done different is copy 2 stereo wavs to the SD and run the loop sketch and record it.
I will test RAW and post again, but I this from above "dsparks" has tried it.
 

Attachments

  • Stereo2Snds100ms.zip
    179.4 KB · Views: 121
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:


View attachment 3286

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. (?)

hi mxxx,

looks like.
mysterious.
one could think that the problem is in output_i2s, but then mp3 must have the same problem. but they say mp3 is ok (?)

i looked at i2s-source, but there's no chance to play a buffer twice, i think.
then, play_sd_raw is very easy and simple. i don't think that there's a bug..
and raw is only mono.
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:


View attachment 3286

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. (?)

hi mxxx,

looks like.
mysterious.
one could think that the problem is in output_i2s, but then mp3 must have the same problem. but they say mp3 is ok (?)

i looked at i2s-source, but there's no chance to play a buffer twice, i think.
then, play_sd_raw is very easy and simple. i don't think that there's a bug..
and raw is only mono.

Code:
void AudioPlaySdRaw::update(void)
{
	unsigned int i, n;
	audio_block_t *block;

	// only update if we're playing
	if (!playing) return;

	// allocate the audio blocks to transmit
	block = allocate();
	if (block == NULL) return;

	if (rawfile.available()) {
		// we can read more data from the file...
		n = rawfile.read(block->data, AUDIO_BLOCK_SAMPLES*2);
		file_offset += n;
		for (i=n/2; i < AUDIO_BLOCK_SAMPLES; i++) {
			block->data[i] = 0;
		}
		transmit(block);
	} else {
		rawfile.close();
		AudioStopUsingSPI();
		playing = false;
	}
	release(block);
}

the for-loop fills the rest of the audioblock with 0, at the end of the file.
 
Last edited:
Just asking: I see that this code allocates a new block every time it is called, whether or not new data is available, and releases it before exiting. Would it not be better only to allocate the block inside the "if (rawfile.available())" block?

David
 
there is almost no difference. the only time when no new data is available is at the end of the file.
i'm beginning to think, that the bug is not in the software.

dpharris, maybe it's a ground-loop or powering-problem ? can you try an other usb-cable (bad connection perhaps) ? can you post a photo ? schematic ?
and, YOUR COMPLETE SOURCECODE
 
Last edited:
Please forgive me if I missed it above in this lengthy thread....

Is there a reproducible bug here? Especially the WAV player has some complex code for parsing the header. There may indeed be more bugs lurking in there, probably entirely my fault.

I'm crazy busy with some non-audio stuff at the moment, but if there's a clear reproducible program and WAV files, I could take a quick look.
 
there is almost no difference. the only time when no new data is available is at the end of the file.
i'm beginning to think, that the bug is not in the software.
Surely update gets called multiple times during the processing of a buffer??

dpharris, maybe it's a ground-loop or powering-problem ? can you try an other usb-cable (bad connection perhaps) ? can you post a photo ? schematic ?
and, YOUR COMPLETE SOURCECODE
It was not me, I just asked a question :)
David
 
sorry :)

no, it's called every 2.9 ms for one buffer (in this case)

Hmm.. the only other tipp i can give is: if teensy 1.20 worked, go back to 1.20
121 is for testing only. its hard to imagine, but it is possible that the new compiler leads to this effect...
 
Frank and Mxxx
Have checked running Play SDRaw..........Raw works OK for 100 ms and 1 second play times. There are no double starts at beginning of play. Sometimes there is a 3 ms silence between the last file stopping and the next file opening to play. I have raw recordings attached. I have only attached the audio files recorded as mp3 to keep the files small but if you all have Audacity you should be able to Zoom in and see.
I think the only double attempts at playback is with stereo Wavs. Mono waves seem OK and MPS OK but 60 ms silence between sucessive files.
 

Attachments

  • SDRawRecorded.zip
    345.1 KB · Views: 124
ok. the 3 ms are normal, and Paul can't do anything on that. it's the way the audiosystem works.
Stereo wa, there could be something with the bufferhandling.
But, to be honest, this code is a bit too complicated for this time of day :) its midnight here. Try to ask Paul again, with complete information about your effect. With your screenshots, the recording, the wav-file and a compilable example in a *.zipfile so that he's able to reproduce the bug.
 
ah, so it's just stereo, after all?

sorry, i can't try to reproduce things atm because i'm nowhere near a teensy (and it's getting midnight ...). the length of the duplicated waveform does look suspiciously like 128 samples though. (it's not quite as clearly visible to me in the attachment to #51, but i guess it's there)

either way, i have no clue where it might come from. as far as i can see, the second time update() gets called (after parsing), buffer_offset should be simply half the buffer size, so the transmit buffers unlikely are filled up from zero again.

Code:
// is there buffered data?
	n = buffer_length - buffer_offset;
	if (n > 0) {
		// we have buffered data
		if (consume(n)) return; // it was enough to transmit audio
	}
 
Last edited:
mxxx
Yes I think it is only the stereo WAV that is the problem, but there is also a slight problem with I think them all an the is the 3 ms gap of silence sometimes. It doesnt happen all the time.......so why some of the time. But for me now it is workable...thanks to all your help and ideas.
I attach 2 more recorded outputs.... one is a 20 ms followed by 100 ms play sounds RAW and no double starts....but gaps of 3 ms in some places...???
The other is a mono WAV followed by a Stereo WAV in the same sketch loop.....and the mono files plays OK with no double start and the stereo following it plays with a double start. The lower freq higher volume is the mono Wav and the higher freq. lower volume is the stereo wav. My recording shows stereo for both.

Paul.....For reproducing the problem use the example sketch or the sketch posted in this thread by dsparks earlier....all produce the same problem....I think...but I will put something together tomorrow and post it in a zip.
 

Attachments

  • SDWavMonoStereo.zip
    302.9 KB · Views: 154
Can you please post all the files, and only those files needed to reproduce the problem in 1 specific way, attached to a single message?

I have very limited engineering time available for audio (until later this year), so this really help maximize the time I spend working on the code, rather than wasting the limited dev time I have right now figuring out which files and which of many possible ways to try.
 
Paul.......This is Zip on the files I used to test. I delayed a bit because I want to test it using the wire.h library. I normally use the i2s_t3.h instead of wire.h because for another project I wanted more touch pads and they used for other functions in the standard teensy audio adaptor setup. I have I2C on pins 29 and 30 when using i2c_t3.h. I was able to test the problem with wire.h and analog output to dac and the problem exists no mater what output I have. I reduced the size of the WAV files when I was doing the Zipped folder so some of my recording may show longer files than on the zip....but all works and should reproduce the problem.......thanks for your help..............
 

Attachments

  • PlaySDWAVPaul.zip
    1.1 MB · Views: 128
dsparks.........I thought I would try your drums sound file converted to mono and played on Teensy and a mono WAV from the SDcard. I plays nearly a good as playing sounds from memory.......except for the odd gap of 3 ms......gaps only happen sometimes.... The file opens cleanly. Recording attached
 

Attachments

  • DrumbeatsMonoRecord.zip
    320.8 KB · Views: 120
You can try aac from flash (not serial) too. mono,with a samplerate ~ 48k (or less?)
It does not need much space.I didn't measure the time, but i think it could be fast enough for drums.

Because of only one channel, the quality will be ok with this low samplerate, i think
But don't use MP4 or M4A as container. Plain AAC is MUCH better.

Edit: Just tried to convert yor 40bp.wav to 40bp.acc mono 56KBps: only 6 KB :)
 
Last edited:
Teenfor3,

Its strange that the sample in momo works ok. That would tell me there is something else going on here.
 
I just made some new samples with varying levels of Db. All much lower than they should be. As well as making them mono. And the issue still persists.

Please note that sample 54BT.wav is the mono wav.
 

Attachments

  • 51BT.wav.zip
    527.7 KB · Views: 114
Are these original sample files or as recorded playback from teensy. If these are samples for SDcard, 51 and 52 looks a better waveform.You have about 5 0R 6 ms of silence at the start anyway so probably would not see or hear any double starting of the stereo files. convert them to mono and format your SD and I think they will play alright. Did you play the Drumbeats zip file I posted earlier. The waveform played very clean and no noticible clicks between. Just some 3 ms gaps but not many. Would mone not be OK for a drum sound. The problem is to do with playing stereo......and Paul is to have a look at it......
 
I would prefer stereo WAV files for my samples.

The zip files I just posted are of the new sample files only.
 
I now have an added problem there is a delayed click at 370 ms after a file opens. I am now playing mono files. Its just a gap of about 1 - 2 ms in the waveform and its not with all files on the SD. This happened about a month ago and I had started another thread at that time about it. I was playing stereo files then and the gap appeared at 185 ms.....and not all files..............I wonder is there any relation......185 ms for stero and 370 ms...for mono..??? .
Otherwise it is still playing the sounds OK. Last time the problem cleared by formatting and copying on new files again....had to do it several times.
This time I have formatted twice and copied on new files twice but problem still there.
 
I attach a recording and jpg to illustrate what is happening. the jpg is from WAV recording in audacity so it is clearer to see. The audio in the zip is mp3 to keep file small so not as clear. I don't know why this happens my setup is exactly same as I have been using for days. the ony difference I copied more files to SD and they worked OK then this started. I formatted and copied new files on and problem still there. And only happens with some of the sound files and not every time as can be heard in the recording.
 

Attachments

  • Recording2sounds370msgap.zip
    392.3 KB · Views: 108
dsparks, Paul,
I have updated my findings on this in my other threads relating to this....... that is the 370 ms delayed glitch with more than 14 mono wavs on SD
I have found now that the problem for me only exists when audio is sent via i2s1 to the Audio Adaptor board. Audio sent to Teensy DAC is OK no glitches for all files even more that 15. .....see the other recent threads
 
dsparks.......
Which glitch is it that you have, Is it the glitch giving double starts to stereo WAVs files......or the glitch at 185 ms after the stereo files starts to play.

OR is it the glitch at 370 ms after a mono file starts to play. And does the mono files start to play correctly with maybe a 3 ms gap between last file played for 2 successive plays without waiting to end of file.

And do you need more than 14 WAV files on the SD before you get the 185 ms or 370 ms delayed glitch.
 
Status
Not open for further replies.
Back
Top