Draw Waveform on display

Status
Not open for further replies.
They answer to every software porting question is, "Yes, if you can compile it and all it's dependencies".

That said, It would likely be impossible to port that application. First off it's an application, not a library you can link against. It has basic dependencies that I don't think are ported (like Boost) and it was designed for output to image files, I don't think it displays them. Even if it does display them, it would be expecting a full blown windowing system like X11 running.

If you want such an application, you would need to write your own and it would likely be customised for a particular display module.
 
Thanks @blackaddr

what I mean was if is possible to look at how that application works, and replicate it on teensy. Just the data extraction from the wave, then on the display is only matter of draw vertical line..i think..
 
Depends on how it works. If it's being 'well designed' for a PC enviroment it will be very minimal code using existing code to parse data in and pixels out. If it really is a monolithic chunk of code that does nothing more complex than call math functions you can certainly graft your favorite drawing functions onto it. Looking at the code also watch for any massive memory assignments to cache waveforms in. PC based code can happily stuff a couple of Mb in RAM to work with, Microcontrollers less so.
 
I have realized that to extract the data necessary to draw the waveform, I have to use the Peak object on the audio library!

Is it possible to read a file audio from the SD card, analyze them with Peaks and save this data somewhere?
I mean, without having to listen to the file.

if yes, there is a sample code in the library?
 
AFAIK, the audio library will process the audio file in real time, that means in normal listening speed, at least as long as you don't resample it before, to increase the virtual reading speed, but losing resolution.

IMHO, it is not necessary to use the (highly specialized) peak object from the audio library. Reading samples from the card, calculating their absolute value and optionally using a first or second order digital filter for a less smooth attack and a smoother decay to make the results better human readable is no witchcraft, can be coded within reasonable time and will allow you much faster processing.
 
This may be overly obvious, but I believe it needs to be said that you're going to have to write some code, and above all else, you're going to have to approach this project as many smaller pieces which you test & troubleshoot, then combine together to form the final solution. Maybe I'm just reading too much into the messages you've already written, but it kinda seems like you're imagining an "easy" solution where almost everything is already done by existing code. Indeed libraries exist for the really tough parts, like reading the SD card and efficiently drawing on the display. But you're going to need to do quite a bit of work on this too. The right mindset, where you get pieces working and build up the solution from well tested parts is needed. If you jump into this expecting some existing code to do almost everything with only a minor edit, you're almost certainly going to end up with frustration.

The first major decision, which Theremingenieur pointed out, it whether to "play" the file at regular audio speed, or just read it directly as fast as possible. If the file is 4 minutes of music, playing the file through the audio lib will end up taking 4 minutes to draw the waveform. Maybe that's what you want? But if you'd like the waveform to appear as quickly as possible, you'll need to read the file directly. You've not said much about *why* you're doing this... we don't have the context to understand if you need it to animate slowly as the music plays, or show up quickly like you'd see in an audio editing program. Aside from the tech details, can you see how better communication here could allow us to help you more? We're real humans with a lot of programming experience, but that expertise doesn't help much if we don't understand what you're trying to do.

No matter how you get the data, you're also going to have to put it into the display. Maybe you've got the ILI9341 display? Or maybe it's some other display?

No matter which display you use, this project is going to involve mapping large chunks of audio data onto each pixel. In this example waveform, it's pretty clear the positive and negative peeks are drawn differently.

example.png

So even if you use the audio lib, the peak object which gives only a single number probably will not be enough. You're probably going to have to get the raw audio data and write a loop to find the min (usually negative) & max (usually positive) values over each range of samples that correspond to each pixel on your display.

How exactly you do that depends on whether you want gradual real-time or render-instantly drawing, and which display, and perhaps other details nobody can't anticipate without knowing more of the purpose of your project.
 
I apologize for the poor informations, but my English is bad.
what I want to do is to visualize the waveform in an instant. Therefore not during audio playback.

For now I have a SSD1306 display that I use with the U8g2 library.
I ordered a 256x64 dot display on bangood but it will arrive in a while.

I was hoping for a simple solution ... but trying to understand more is fine.
 
Status
Not open for further replies.
Back
Top