Is there a way to do fast forward / rewind with playback?

[0x0fe]

everything is in the title, to be used with FF and rewind key when there is no UI, so the playback is the only feedback possible to know where we are at in the file.

[pschatzmann]

play back from where using which functionality ?
There are about 100 different way to play audio with this framework....
What would FF exactly do ?

[0x0fe]

for example when using the player from SDMMC

[pschatzmann]

If you look at the api you can position to any file using the index position...
You could play at any speed if this is what you mean with FF by using a ResampleStream

[0x0fe]

i have seen set index, but this is not what i can use (because there is no UI). What i mean is accelerated playback, forward and backwrd, same as if you hold the FF or RW key on a CD player for example.

[pschatzmann]

I don't understand why you think you would you need a UI and there are also the next and prior methods for navigating back and forward.
I suggest that you look at this example which uses the buttons of the audiokit

[0x0fe]

but, next and prior is to change to the next/previous file, right? what i mean is the standard transport function inside the file, to navigate the content of the file with an audio feedback

[pschatzmann]

Well you can use the regular file operatons to (re)set the actual file position....
I don't know what you mean with with an audio feedback

[0x0fe]

mmh, no, you never used fast forward and fast rewind on an audio player? the playback is accelerated, and when using rewind it plays backward (also accelerate), files operation or setting playback position on the file are of no help to acheive that.

[pschatzmann]

No, I have never seen such a functionality!
Playing fast forward is feasible but playing audio backward does not make any sense !
What would make sense if moving the file pointer back and restart to play forward

[0x0fe]

well, that is what most player devices do, when fast rewind with playback the audio is played in reverse direction, i believe that is also what CD players do. In fact i dont really see how you could do fast rewind with playback and play the audio in the forward direction.
Here is a sample from an MP3 player, when holding the FF and RW keys we can hear the fast playback, forward and backward.
transport_test.zip

[0x0fe]

well, it would not make any sense on a computer because you have an UI and the index is set with visual feedback on a timeline. But many simple audio devices with only 3 or 4 transport keys do not have any kind of UI and for the last 40 years this is how things have been done to navigate a long file / media, with audio feedback when using fast forward/rewind. Most MP3 SoC do implement this too. Moving the file pointer will maybe work in forward direction, but for reverse i have doubts.

[pschatzmann]

Yes, for everything which is file based this works. The good thing with MP3 is that if you do not reposition on a frame boundry the content is usually just ignored until you hit the next full frame. On WAV files you can move to any position which is a multiple of (bytes per sample * channels)
But it will not work on any medium which does not have any file repositioning fuctionality. (e.g. URLStream)

[0x0fe]

yes, that is convenient, I am now trying to implement the FF and RW functions, so i will determine how many chunk should be read / skipped based on the file length and bitrate then perform file seeks at regular interval as long as the FF/RW keys are held, I wonder, where i should perform the seek operation? Is it in the copier? i currently use AudioSourceCallback rather than AudioSourceSDMMC due to the changes in indexing / file select methods.

[pschatzmann]

I suggest that you just perform the seek when pushing the button. The most generic way to access the current playing file is by calling the getStream() method on the player which returns a pointer to a Stream and if you use any file related streams you can just cast it to a File pointer.

[0x0fe]

oh, i see, directly seeking audioFile from the keys handler, outside of the library, that makes sense since i manage the file directly now.

[0x0fe]

ok, so the file seek works on the princple, now i need to find a way to performs very short fade ins/outs and also control how many chunks are copied/played between the seeks, so that the result sounds ok. At the moment it creates artifacts, presumably due to sharp amplitudes transitions outside zero crosses.

[pschatzmann]

We could expose the fade object in the Player with a public method

[0x0fe]

Oh, this is new, seems i should update to the lastest commit and use this, once i figure out how it works.

[0x0fe]

I got this message when i start the stream, but i am not using fade here, is there something else i need to initilize with the new changes?

I have the notifiychange set

So, it seems that this function should be called somewhere, maybe in AudioSourceCallback, but its not.

[pschatzmann]

I am wondering what you do to write to the output before the mp3 could inform i2s and the player about the audio format. I suggest that you set the log level to debug.
Oh I see, so I suggest to remove your logic since this is automatically handled, and if you want to keep it you should not notify I2S but the player

[0x0fe]

in fact i kep the same i did before and just changed the library, i only have 3 callabcks, init, select and next

When i start playing, all i do is indexing files, selecting index 0 and player.begin

Note taht the select callback is assigned to source object, because there is no public access to this callback in player.

[0x0fe]

if you want to keep it you should not notify I2S but the player

Ah, that makes sense, i change to player rather that I2S

Edit : it works now

[0x0fe]

So from what i understand of the new player code, it should be able to just use player.setActive() to performe automatic fade-in and fade-outs when i need, so i implemented it that way, seekCnt counts the number of chunks copied by player.copy (increased when returns a value), so essentially i skip 5 chunk with file.seek, and play 150 chunks, i would like to perform the fade in and fade out on the first and last chunk of the played section (150 chunk). But it doesnt seems to work with player.setActive(). Should i proceed differently?

[pschatzmann]

I think the easiest would be to move the copy logic directly into your navigation: call the copyN(), then fade out and then a final copy. You would need to have access to the copier though

[0x0fe]

but the copy logic is ok, and i really hneed to avoid blocking the main loop, my question was more related to the fade in and fade out, is player.setActive appropriate here? or should i call some lower level function from fade.h?

[pschatzmann]

I would really think that blocking the main loop might help.
In any case, try the easy thing first...

[0x0fe]

i cannot block the main loop because several other unrelated functions are using it. I want to try performing the fade "manually" but i still havent figured how it should be done by looking at fade.h, i try to find some examples in the other files.

[mydroidbox]

Hi 0x0fe, I've been trying to acheive this ffwd and rewind for a couple days but
I confess the code is above my head. Could you share a copy of your final implementation.
That would greatly appreciated. Thanks.

[0x0fe]

hello, sorry i missed the message, i implemented it yes, but its not working correctly still. I will tell here when it is working fine, as of now i have more major issues to solve with this because there is still farting noises when using the transport functions.

[bool-shark]

Thanks, appreciate it.

[0x0fe]

so, i havent found a fully satisfactory way to implement this, but i'll give what i currently have and is the less worst so far, this implies the tact switches handler is in the same thread which serves player.copy, i dont show the key handler here because it is not useful, basically when key is just pressed it will call the transport function and when key is held if will call these seek functions instead (ff and rw).
Also something important : i had to modify the buffer sizes in the library wide preferences, because with default values it wil gllitch and produce very unpleasant noise artefacts, probably due to buffering issues. As far as i can tell , APP and AUTO_CLEAR state have no influence on the seek function, but buffer size do.
The last player.copy is in a "for" statement because i tried to play a longer segment after the seek, however with the increased buffer size it ended up impacting the seek repeat time too much. So finally there is only one player.copy after seek, and the seeks is already quite sluggish.

#define DEFAULT_BUFFER_SIZE 2048
#define I2S_BUFFER_SIZE 1024
#define I2S_BUFFER_COUNT 20 
...
#define I2S_USE_APLL false 
#define I2S_AUTO_CLEAR false

void ff(void){  
  if(!digitalRead(KEY1)){
    player.setActive(0); // fade out
    player.copy();      
    audioFile.seek(audioFile.position()+(1024*30));      
    player.setActive(1); // fade in
    for(int i=0;i<1;i++)player.copy();  
  }  
}
void rw(void){
  if(!digitalRead(KEY3)){
    player.setActive(0); // fade out
    player.copy();      
    audioFile.seek(audioFile.position()-(1024*30));      
    player.setActive(1); // fade in
    for(int i=0;i<1;i++)player.copy();  
  }  
}