Strange issues with different formats

[fauri]

Hi, Fred and everyone.

I'm having somes issues with different formats (ogg, mp3 and wav, specifically). For example: using this command:

> uos_AddIntoDevOut(0, -1, -1, -1, -1, 0, -1);

Only mp3 files play well... Ogg and Wav formats sound very strange (faster play, something like that). But, if I change the Channels parameter:

> uos_AddIntoDevOut(0, -1, -1, -1, 1, 0, -1);

So, ogg and wav sounds better, but with a kind of cut at the end. Also, mp3 files looks awful with this change.

All files (attached) I've tested are stereo, from de same sound (converted by Audacity).

Thanks.

---------
Taking advantage of the post, I also noticed that uos_Play has a small delay to run for the first time. Is it possible to minimize this effect?

sound_test.zip

[fredvs]

Hello.

I have tested your files with SimplePlayer uos demo for each resolution (int16, int32, float32) and all is perfect.
Please take a look a SimplePlayer demo code.

> I also noticed that uos_Play has a small delay to run for the first time. Is it possible to minimize this effect?
Huh, I can not feel it, could you give a example.

Fre;D

[fauri]

> Please take a look a SimplePlayer demo code.

Ooops... sorry for giving you more desnecessary work to do... I had not yet realized the need to use uos_InputGetSampleRate and uos_InputGetChannels inside uos_AddIntoDevOut... They did the trick!

About uos_Play, I'm using at least 3 sounds being executed in same time (me and my neverending drum machine, remember, Fred? ahahaha)... It's a small delay, like a half second or less. I realized that when I press a key or button to play, it's not instantly executed (I achieved an "almost real time play" only when I used uos_PlayNoFree and uos_Pause before starts execution -- and, inside the loop, I call uos_PlayNoFree again and again). But we've talked about uos_PlayNoFree before... the out of sync effect when more than one sound is playing at the same time is the big problem.

Cheers!

[fredvs]

> e and my neverending drum machine, remember, Fred?

Huh, did you see that SimpleDrum.lpi demo was added, maybe there are interesting things for you... ;-)

Fre;D

[fauri]

Yeap, I've tried before. But there are two problems:

1) Beats sounds "choppy". You'll be noticed that the problem is FramesCount parameter. But it's hard to set: with small values, there are a cut in the end (beats should keep sounding); and, increasing the frames number, more out of sync occurs.

2) Still there are desynchronization moments with this method, mostly with small times between loops.

So far, for me at least, the best method is creating a player and execute it in each loop.


PS: In my tests, uos_free always crashes the executable (in windows 10 x64, with LCL gui).

[fredvs]

> there are a cut in the end (beats should keep sounding);
Demo fixed in last commit.

> So far, for me at least, the best method is creating a player and execute it in each loop.
Strange, I will investigate one more time.

> uos_free always crashes the executable
...
sleep(50); // add this
uos_free();

Fre;D

[fauri]

> > there are a cut in the end (beats should keep sounding);
> Demo fixed in last commit.

Hum... No changes here. Sounds are still cut off at the end.

> > uos_free always crashes the executable
...
> sleep(50); // add this
> uos_free();

I still get the same error.

[fredvs]

> Hum... No changes here. Sounds are still cut off at the end.

Strange, here it keep playing.
OK, I will re-jump into it.

> I still get the same error.

Aaargh, sorry but I think that I will need to see your code.
Do you get the error with one of uos demos ?

Fre;D

[fauri]

> Strange, here it keep playing.
> OK, I will re-jump into it.

Well, I imagine that the best way is show to you how it's sounding, and how it should be. I put it in attachment (don't consider the time differences between files).


> Aaargh, sorry but I think that I will need to see your code.
> Do you get the error with one of uos demos ?

With new release, the error only happens when I tried to close while uos_Play is still playing (maybe there should be a way to force to terminate before call uos_free).

Thanks!
how_its_sounding.mp3
how_it_should_be.mp3

[fredvs]

> With new release, the error only happens when I tried to close while uos_Play is still playing (maybe there should be a way to force to terminate before calls uos_free).

Ha, ok. Maybe if you add on Form.ondestroy()

uos_Stop(0); /// even if player was already stop.
uos_FreePlayer(0); // in case of uos_PlayNoFree() was used.
sleep(50);
uos_Free();

But ok, I will see if I can add a "auto-stop" in uos_free().

>how_its_sounding.mp3
>how_it_should_be.mp3

OK, capito, I will check why it does not maintain sound.

Write you later.

Fre;D

[fredvs]

>  tried to close while uos_Play is still playing

Ok, added "auto-stop" of players in uos_Free() in commit c06bc7c..c5642af.

About your drums, I will try asap to find something better.

Fre;D

[fauri]

Thanks a lot, Fred. But remember that creating a player in each loop works fine. The only thing is there are a bit delay before uos_Play first execution (and a musician would expect an "almost" realtime response when press or click to play.

PS: uos_PlayNoFree should be the definitive solution in this case, I guess... But will be necessary to find why desynchronism happens when using uos_InputSeek and uos_PlayNoFree if more sounds are executed together.

[fredvs]

Hello Fauri.

Thanks for the tips. ;-)

OK, I will try to find (lot of) time to explore a better way.

Write you later (asap).

Fre;D

[fauri]

Hi, Fred! So, I believe I discovered the origin of delay problem with uos_Play: LATENCY.

After many tests, changes, and so on, finally I realized how to use the latency parameter with uos_AddIntoDevOut:

> uos_AddIntoDevOut(0, -1, 0.04, -1, -1, 0, -1)

After this change, uos_Play executes very quickly. I imagine that 0.04 = 4ms, am I right?

Take advantage of the topic, I noticed that uos_InputGetSampleRate and uos_InputGetChannels don't work when I use uos_AddFromMemoryBuffer. Some like that:

> buffer := uos_File2buffer(Pchar(file), 0, buffer);
> input := uos_AddFromMemoryBuffer(0, buffer, -1, -1, -1, 0, 1024);
> uos_AddIntoDevOut(0, -1, -1,uos_InputGetSampleRate(0, input),
                                   uos_InputGetChannels(0, input), 0, -1);

Am I doing something wrong?

[fredvs]

> Hi, Fred! So, I believe I discovered the origin of delay problem with uos_Play: LATENCY.

Ha, yes, it could be that.

>  I noticed that uos_InputGetSampleRate and uos_InputGetChannels don't work when I use uos_AddFromMemoryBuffer. :

Ok, I will take a look.
I hope to have some time this week to jump back in uos code.

Thanks to note it.

Fre;D

[fredvs]

fauri wrote

Hi, Fred! So, I believe I discovered the origin of delay problem with uos_Play: LATENCY.

After many tests, changes, and so on, finally I realized how to use the latency parameter with uos_AddIntoDevOut:

> uos_AddIntoDevOut(0, -1, 0.04, -1, -1, 0, -1)

After this change, uos_Play executes very quickly. I imagine that 0.04 = 4ms, am I right?

Take advantage of the topic, I noticed that uos_InputGetSampleRate and uos_InputGetChannels don't work when I use uos_AddFromMemoryBuffer. Some like that:

> buffer := uos_File2buffer(Pchar(file), 0, buffer);
> input := uos_AddFromMemoryBuffer(0, buffer, -1, -1, -1, 0, 1024);
> uos_AddIntoDevOut(0, -1, -1,uos_InputGetSampleRate(0, input),
                                   uos_InputGetChannels(0, input), 0, -1);

Am I doing something wrong?

Hello.

I have taken a fast look and do not see something wrong.
Your code is ok.

What does not work ?

Fre;D

[fredvs]

Re-hello.

Could you try this:

 buffer := uos_File2buffer(Pchar(file), 0, buffer);
 input := uos_AddFromMemoryBuffer(0, buffer, -1, tempchan, tempSamplerate, 0, 1024);
 uos_AddIntoDevOut(0, -1, -1, tempSamplerate, tempchan, 0, 1024);

With File2buffer, uos_InputGetSampleRate and uos_InputGetChannels does not work (yet).
You should use tempSamplerate and  tempchan instead.

I will do something more "universal" asap.

Fre;D
 

[fredvs]

Hello.

Fixed in last commit 9b1e8b3..f4ffcc7.

Thanks to note it.

Warning, some methods have new parameters, please take a look at consoleplaymemorybuffer.pas demo.

Fre;D

[fauri]

Something is wrong in the last commit (revision 169). Some sounds don't play anymore, and others are being cut off at the end (maybe a problem with framecount parameter). When I did a downgrade (revision 168), everything worked fine again.

[fredvs]

Hello.

With what method, AddFromMemoryBuffer or with everything ?

Fre;D