WAV file handling

A "new fashioned" televisor, using an Arduino to drive the motor and display.

Moderators: Dave Moll, Andrew Davie, Steve Anderson

WAV file handling

Postby Andrew Davie » Wed Mar 15, 2017 3:39 pm

Now that I'm going to be playing WAV files direct from a SD card, I have to think about how to decode/interpret them.
A pretty good starting point is the Arduino library for asynchronous playback of PCM/WAV files direct from SD card. Arduino Uno,Nano,Mega etc supported. I'm going to need to modify it a bit - but since all the source code is there and it doesn't look too complex, I don't think that will be a problem. Essentially it has two buffers into which it reads a block of audio data. It then uses interrupts to play that data and while that's happening, load new data into the other buffer. It appears to have volume processing, too. I am pretty sure this is essentially a complete shell for what I want to do anyway.

It does have limitations - 32kHz sampling rate. 8-bit mono. So this will be video only, and I'll have to convert my files to suit. Will dig into the code sometime soon and see if it's feasible to use.

There's a Wiki for this project
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Klaas Robers » Wed Mar 15, 2017 10:00 pm

The nice thing of a CD-player is that you don't have to bother about the sound. That is analoguely coming out of the red output. If you stored and read back the wave file, then you have to see that you play it in the proper speed and you have to handle the 16 bits sound channel.

But there is another way. The better CD-players output next to L and R analogue audio as well a digital data stream. It is a fast serial stream, but that can be parallelised by a certain IC. Together with Vic and Karen we did this for Compatible Colour NBTV. May be you could look into what Vic did and use the same circuit. Then you have direct access to the digital data stream of the left channel of the running CD. And also here, the sound channel is not processed, it is already analogue.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: WAV file handling

Postby Andrew Davie » Thu Mar 16, 2017 12:08 am

Klaas Robers wrote:The nice thing of a CD-player is that you don't have to bother about the sound. That is analoguely coming out of the red output. If you stored and read back the wave file, then you have to see that you play it in the proper speed and you have to handle the 16 bits sound channel.

But there is another way. The better CD-players output next to L and R analogue audio as well a digital data stream. It is a fast serial stream, but that can be parallelised by a certain IC. Together with Vic and Karen we did this for Compatible Colour NBTV. May be you could look into what Vic did and use the same circuit. Then you have direct access to the digital data stream of the left channel of the running CD. And also here, the sound channel is not processed, it is already analogue.


Ah, but I already have it 90% working :)
I am reading a WAV file off the SD card, processing the header, stereo, 16/8 bit, grabbing the two channels (audio/video), filling dual buffers from the file asynchronously while interrupts are servicing the output pins (one analog for sound, one for the PWM duty cycle for the video). I have pretty much abandoned the idea of using a CD player as souurce. I can just dump a WAV file on a MicroSD card MUCH easier these days, and as I said... code's nearly complete.
I'll hopefully have it running properly tomorrow.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby gary » Thu Mar 16, 2017 2:00 pm

Does that mean I'll have to buy The White Album *again* ????


youtu.be/WRflvORaJO4

PS: we had a saying back in my software development days: "the last 10% takes 90% of the time", which sort of matched "the sooner you get behind, the more time you have to catch up!"
gary
 

Re: WAV file handling

Postby Andrew Davie » Thu Mar 16, 2017 11:53 pm

Well, my prototype is now functional. Not great, but functional!

standalone.jpg
standalone.jpg (346.52 KiB) Viewed 7352 times


This is about an hour after I got my first picture. I have a WAV file on the MicroSD card on the Arduino. I wrote/adapted code to read and interpret the WAV file, then stream the sound and video data off the card asynchronously while a timer interrupt running at 44.1kHz is "playing" that data. It's all doing that well, but I'm not sure I have it at the right frequency. Seems to me the image is playing at just half speed so I have my disc spinning quite slowly.

But still, a recognisable picture! And obviously there's some real shading/contrast issues and I'm pretty sure that's where the gamma correction comes in. But I have plenty of processing power left to do that. Oh, another thing - for some reason the WAV file data appears to be negated (I had negative pictures). Not sure what's going on there, but again, not a major issue.

I suspect my LED PWM frequency is interacting with the picture and sometimes we see "off" - I will be fixing that soon.


youtu.be/1KojGobB0nY

Well, lots of things to fix - but as it stands now, none of the original analog circuitry is attached, and I have a NBTV picture. Just! But that was the hard part! Quite pleased to call it an early night this time, and have a celebratory night off.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Andrew Davie » Fri Mar 17, 2017 1:19 am

Figured out one of my issues - not sure how to fix it yet. The frequency of the PWM for the LED array needs to be the same frequency as the video signal (i.e., 44.1kHz) or better yet, double. It's quite possible to see distinct on and off bands when the disc is spinning, because for "long" periods of time the LED is in on or off, and so we aren't seeing shades of grey in any one "pixel". I'm juggling timers and pinouts and resources and it's a bit of a mess that I have to resolve. The ATmega32U4 is very configurable, but consequently a bit confusing. You can have different pinouts attached to different timers, running different frequencies. I need to have a bit of a cleanup/housekeeping and see if I have sufficient resources. It's very easy to get unexpected "cross effects" where you do something with one set of registers and it unexpectedly affects something completely unrelated. For example, I might set the duty cycle of the LED and suddenly my IR sensor no longer works. That's because I'm not setting up all the various indirections properly and basically have no clear understanding of what I'm doing :P Getting there, but this is a major thing to fix before moving on.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby gary » Fri Mar 17, 2017 9:28 am

You are using 44.1kHz? That's making a rod for your own back.

Why not pre-process the audio, before loading it on to the SD card, by resampling it to an integer multiple of the signals pixel rate? (32 x 48 x 12.5 = 19200) or at least the line rate 24k, 32k, 48k etc).

*Not* doing that will make it a) harder to process the sync pulses (because their edges fall between the samples) and b) introduce aliasing effects into the picture.

My previous (perhaps hasty) assertion that you won't need a reconstruction filter was predicated on there being an integer multiple relationship between the signal and both the sample rate and the modulation frequency (which itself should be an integer multiple of the signal sample rate).

In any case, since it is so easy to do, I recommend you resample (as above), in the first instance, just to reduce the number of variables you have to worry about.

Thinking about this made me also think about the possibility of non-linearities in the driver transistor causing problems, being high gain and saturated I don't think that will be a problem but it is at least something to keep in mind if there are problems later on.

Having said all that, your system is showing great promise. :-)

(PS: I just want to make sure you know I do realise you "twigged" to the sampling issue more or less yourself, I just wanted to expand on it.)
gary
 

Re: WAV file handling

Postby Andrew Davie » Fri Mar 17, 2017 11:31 am

gary wrote:You are using 44.1kHz? That's making a rod for your own back.


Maybe. Maybe not! We'll see, as my wife says.

Firstly, I wanted to be able to play just about anything you throw at it. I'm a big believer in "generic" stuff - and so, the 44.1kHz is just an artefact of the CD frequency and what the WAV files just happen to be holding. There's nothing particularly set in stone about it, but I would prefer people to not have to preprocess any NBTV file they find as a WAV just to be able to play it on this thing.

Secondly, because my code reads the WAV header and sets the output frequency based on that, theoretically it can handle a wide range of input frequencies. Furthermore, it should also handle a wide range of frame rates - if you want to encode at 25fps well then provided my motor can spin the disk that fast (it can't at the moment but a bit of a larger wheel on the motor will make that possible) well then, that's easy!

But that brings us to the next "hey I could do that!" moment. It wouldn't take too much effort to add fast forward and rewind and pause to this televisor. Because I have complete control over the WAV playback and the frequency at which I play the signal, fast forward is simply skipping one or more frames. Rewind is keeping a track of the "frames" and after each one is done, skipping back in the WAV stream. And pause, of course, is just playing the same frame over and over. I'm not sure I'll add these - but just wanted to document that they are not that difficult at all!

Another option is to increase the frame rate of the disc; this will give a rudimentary fast forward just by changing the playback frequency which will in effect spin the disc faster. However, I could rig it so that the WAV playback is feeding frames to the LEDs at appropriate frequency and frame rate for normal speed (i.e., 12.5Hz frame rate) but for playback at (say) 25Hz. Lots of options available which I might play with later.

So that's a bunch of reasons why I don't want to pre-process the file.

gary wrote:*Not* doing that will make it a) harder to process the sync pulses (because their edges fall between the samples) and b) introduce aliasing effects into the picture.


I don't think it's making it harder. If you take a 44.1kHz file and subsample it or upsample it, you still have inconsistent edges. It depends on your point of view; from the original analog source then yes, you may have an edge between samples. If you resample then your edges are going to be inconsistent, possibly, based on the ratios of sampling frequencies. However, I'm only intersted in the sync pulse on the very first scanline anyway. And I plan to have an adjustment so you can delay (positive or negative direction) the sync pulse, giving you a frame vertical adjust. Watch this space, I guess.

gary wrote:My previous (perhaps hasty) assertion that you won't need a reconstruction filter was predicated on there being an integer multiple relationship between the signal and both the sample rate and the modulation frequency (which itself should be an integer multiple of the signal sample rate).


I expect to be able to drive the LED at a faster rate than "a single pixel" but in any case for the vertical scanning, the concept of "pixel" is very loose. You need to drive the LEDs fast enough that you don't notice that they're off. And that means that the physical distance the scanline hole sweeps is small enough while the LED is off that you don't really notice it. That would come down to the eye's ability to distinguish such small distances. I'm not too concerned about this, actually - provided I can jack the LED PWM right up I think the problem won't be noticeable.

It does bring up the point, though, that I really would have preferred NOT to use PWM for the LED control, but I just don't understand/know how I could do this, when all I have as an option on the Arduino pins is a PWM output.

gary wrote:Having said all that, your system is showing great promise. :-)


I'm happy to be doing something "new" (although at least one other has done an Arduino televisor). But I'm creating something with a bit of my own design decisions, and that makes me feel a little less useless :P

Thanks for your comments/feedback!
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Andrew Davie » Fri Mar 17, 2017 11:54 am

gary wrote:Does that mean I'll have to buy The White Album *again* ????


I'll pitch the NBTV format to some record companies, see how it goes. You may very well have to!
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Klaas Robers » Sun Mar 19, 2017 12:45 am

I wonder what the PWM generator does if you change the value while it is going. This is because the pixel clock is in almost the same speed as the PWM clock, so reprogramming the PWM value is done quite frequently.

And then you have an extra problem, because when PWM modulating the LED brightness you have a linear system. Your eyes are no linear, that is where the gamma comes in. If you want to have 64 grey levels in the eye apreciation then you need 3 bits more, i.e. 512 levels of brightness.

If your clock frequency is 16 MHz, and with 512 levels, the PWM frequency will be 32 kHz. Rather low, as your pixel speed is about 20 kHz......
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1656
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: WAV file handling

Postby Andrew Davie » Sun Mar 19, 2017 12:51 am

Klaas Robers wrote:I wonder what the PWM generator does if you change the value while it is going. This is because the pixel clock is in almost the same speed as the PWM clock, so reprogramming the PWM value is done quite frequently.

And then you have an extra problem, because when PWM modulating the LED brightness you have a linear system. Your eyes are no linear, that is where the gamma comes in. If you want to have 64 grey levels in the eye apreciation then you need 3 bits more, i.e. 512 levels of brightness.

If your clock frequency is 16 MHz, and with 512 levels, the PWM frequency will be 32 kHz. Rather low, as your pixel speed is about 20 kHz......



Yes, I'm trying to abandon the PWM modulation of the LEDs, so I hope you are reading my other posts! I also wondered what would happen when you change mid-flight. I can in theory make the LED PWM much quicker (16000000/128 = 125kHz) but in any case I think a moving disc over a PWM LED causes artefacts that I don't want. I am trying to understand if I can use a digital potentiometer instead to control the current to the LED array.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Andrew Davie » Mon Mar 20, 2017 12:04 am

gary wrote:It's a tried and proven approach Andrew, are you an NBTVA member? There are examples in the Newsletters.


Well, technically no I'm not a member. But I've been receiving newsletters so somebody must be paying my membership or I'm in arrears for several years.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: WAV file handling

Postby Steve Anderson » Mon Mar 20, 2017 11:35 am

Klaas Robers wrote:I wonder what the PWM generator does if you change the value while it is going.

I can only speak for the PIC series I use. The PWM module only loads a new duty-cycle value at the end of the PWM cycle in progress. Let's say the PWM waveform is at 100kHz so the update could be up to 10us late, the average being 5us. I may be missing something here but the eye cannot respond to even a 10ms error, so I can't see any issue (pun intended).

I think this is backed up by Steve O's colour disk monitor where the LEDs were driven by a 100kHz PWM signal. Steve didn't report any artifacts. However, this was done with simple analogue comparators, not using any software-driven system. Even so, I doubt there would be any problem here.

In terms of positional error, a line is 2.5ms in duration (2,500us), an error of 10us results in an error of 1/250th of a line, the average being 1/500th of a line.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: WAV file handling

Postby Steve Anderson » Mon Mar 20, 2017 12:04 pm

...thinking further on my post above, if the ADC and the PWM module are clocked from the same source the delay would be constant. Say PWM at 100kHz and ADC sampling at 25kHz. As long as the code is isosynchronous with no variable duration branches or loops then all should be well...I think.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: WAV file handling

Postby gary » Mon Mar 20, 2017 4:52 pm

Sorry to keep throwing fuel on the fire Andrew, but I came across these two articles that are interesting if nothing else:

http://apcmag.com/play-wav-filesn-arduino-nano.htm/

http://apcmag.com/arduino-projects-digi ... art-2.htm/

It would seem the recording part was even more doable than the playback (up to 77Khz if you don't mind a little jitter in the 2 LSBs - heck we engineers do that purposely!).
gary
 

Next

Return to Andrew Davie's Arduino Televisor

Who is online

Users browsing this forum: No registered users and 1 guest