Synchronize(dummyproc) with Linux.

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Synchronize(dummyproc) with Linux.

fredvs
This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows)
Have some trouble with threads synchronize() procedure.
The main thread.execute is a loop to read-write audio data.
Inside the loop i use synchronize(myProc) to synchronize some graphic component ( like taskbar.position, position.text,...). With LCL the graphic synchro is good and the quality of sound is ok and not altered with synchronize(myProc). With fpGui the synchro is good but not the quality of sound.
Some audio chunk are omitted when using synchronize(myProc).

I was thinking that the reason was the Graphic-refresh  but it is not.
If i do a synchronize(dummyproc) i have the same bad result.
Without synchronize(dummyproc), the sound is perfect.
Here some code :

>>The main thread.execute
procedure TUOS_Player.Execute; begin ... repeat ... if LoopProc <> nil then synchronize(LoopProc); ... end; end;  
>> And here LoopProc := DummyProc :  
Procedure TSimpleplayer.DummyProc ; begin // Nothing ! end; I have a test example for Linux 64 bit. There are 3 binaries from same code : fpGUI, GTK2, Qt. On the fpGUI demo, there are 3 checkboxs more, - With syhchro Grahic - With synchro Dummy - Without syhchro On my slow computer, the sound is altered while using synchro, even if the proc is dummy ! Why, what do synchronize() if the procedure is dummy ? Here the demo test : https://sites.google.com/site/fiensprototyping/fpGUI_UOStest.tar.gz Download the zip file, and run the binaries in root folder (everything is included and ready to use). The source are in src. Many thanks


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
Ooops, it seams that the link of the demo was wrong. Here the good one :
https://sites.google.com/site/fiensprototyping/fpGUI_UOStest.tar.gz
Thanks

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Synchronize(dummyproc) with Linux.

silvioprog
In reply to this post by fredvs
2013/4/30 Fred van Stappen <[hidden email]>
This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows)
Have some trouble with threads synchronize() procedure.
The main thread.execute is a loop to read-write audio data.
Inside the loop i use synchronize(myProc) to synchronize some graphic component ( like taskbar.position, position.text,...). With LCL the graphic synchro is good and the quality of sound is ok and not altered with synchronize(myProc). With fpGui the synchro is good but not the quality of sound.
Some audio chunk are omitted when using synchronize(myProc).

I was thinking that the reason was the Graphic-refresh  but it is not.
If i do a synchronize(dummyproc) i have the same bad result.
Without synchronize(dummyproc), the sound is perfect.
Here some code :

>>The main thread.execute
procedure TUOS_Player.Execute; begin ... repeat ... if LoopProc <> nil then synchronize(LoopProc); ... end; end;  
>> And here LoopProc := DummyProc :  
Procedure TSimpleplayer.DummyProc ; begin // Nothing ! end; I have a test example for Linux 64 bit. There are 3 binaries from same code : fpGUI, GTK2, Qt. On the fpGUI demo, there are 3 checkboxs more, - With syhchro Grahic - With synchro Dummy - Without syhchro On my slow computer, the sound is altered while using synchro, even if the proc is dummy ! Why, what do synchronize() if the procedure is dummy ? Here the demo test : https://sites.google.com/site/fiensprototyping/fpGUI_UOStest.tar.gz Download the zip file, and run the binaries in root folder (everything is included and ready to use). The source are in src. Many thanks
Try Queue instead Syncronize.
 
--
Silvio Clécio
My public projects - github.com/silvioprog

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs

Try Queue instead Syncronize.
 
--
Silvio Clécio
My public projects - github.com/silvioprog

Thanks Silvio, i gonna try. But i want to understand why it does not works good with Syhchronize. I was thinking that, maybe, LCL does not use the same level of priority while creating thread than original fp. Is that wright ? And why Synchronize a dummy proc have affect on parent thread.
Other question :
Does it exist a level of priority for Synchronize, like threads have ?
Thanks

_______________________________________________ fpc-pascal maillist - [hidden email] http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Synchronize(dummyproc) with Linux.

Graeme Geldenhuys-3
In reply to this post by fredvs
On 01/05/13 00:31, Fred van Stappen wrote:
> With fpGui the synchro is good but not the
> quality of sound.
> Some audio chunk are omitted when using synchronize(myProc).


And on my 64-bit Linux (Ubuntu 10.04) VM the sound and graphic updates
are perfect - no audio interruptions at all.


Regards,
  - Graeme -


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Synchronize(dummyproc) with Linux.

Sven Barth-2
In reply to this post by fredvs
On 01.05.2013 01:31, Fred van Stappen wrote:

> This about audio and fpc and fpGUI and LCL and Linux. (working good with
> Windows)
> Have some trouble with threads synchronize() procedure.
> The main thread.execute is a loop to read-write audio data.
> Inside the loop i use synchronize(myProc) to synchronize some graphic
> component ( like taskbar.position, position.text,...). With LCL the
> graphic synchro is good and the quality of sound is ok and not altered
> with synchronize(myProc). With fpGui the synchro is good but not the
> quality of sound.
> Some audio chunk are omitted when using synchronize(myProc).
>
> I was thinking that the reason was the Graphic-refresh  but it is not.
> If i do a synchronize(dummyproc) i have the same bad result.
> Without synchronize(dummyproc), the sound is perfect.
> Here some code :
>

With Synchronize you need to keep in mind that the execution of the
calling thread will be blocked until the given method was executed in
the context of the main thread. So if the main thread doesn't call
CheckSynchronize often enough your thread will hang longer (Note:
CheckSynchronize is internally called by the event loop of the
widgetset). Like Silvio said if you use FPC 2.7.1 you should use the new
Queue method instead of Synchronize, because this won't block the
calling thread. Alternatively you could try to use
Application.QueueAsyncCall (only available for LCL applications).

>
> I have a test example for Linux 64 bit.
>
> There are 3 binaries from same code : fpGUI, GTK2, Qt.
>
> On the fpGUI demo, there are 3 checkboxs more,
> - With syhchro Grahic
> - With synchro Dummy
> - Without syhchro
>
> On my slow computer, the sound is altered while using synchro, even if the proc is dummy !
> Why, what do synchronize() if the procedure is dummy ?

Do you use fpGUI directly or fpGUI through the LCL?
In both cases it could be the case that the event loop is doing a
CheckSynchronize to seldomly. Maybe you should better ask this on the
lazarus mailing list, so that the Lazarus devs could adjust this if it
is a problem in the fpGUI glue code for the LCL.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
In reply to this post by Graeme Geldenhuys-3
> And on my 64-bit Linux (Ubuntu 10.04) VM the sound and graphic updates.

That are good news ;)
But does not respond to the question :
Why synchronize a dummy-empty proc affect the parent thread ( and in this case the main thread is a audio process) ?
Sure that with good cpu you do not feel it. But with a atom cpu, very close than arm cpu, i can test the result live. And trust me, something append while synchronize a dummy proc. And i really want to understand why.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
In reply to this post by Sven Barth-2

>Do you use fpGUI directly or fpGUI through the LCL?
i use fGUI directly.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Synchronize(dummyproc) with Linux.

Graeme Geldenhuys-3
In reply to this post by fredvs
On 01/05/13 20:45, Fred van Stappen wrote:
> you do not feel it. But with a atom cpu, very close than arm cpu, i
> can test the result live. And trust me, something append while
> synchronize a dummy proc. And i really want to understand why.

Like I said before, I have no idea why that is the case on your system.
If I can find a similar reproducing example, I'll test it on my
Raspberry Pi - that is the slowest system (by a big margin) I have
available.


Regards,
  - Graeme -
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
> that is the slowest system (by a big margin) I have
> available.

Im very interested by the result.
But i continue to think there is something strange with synchronize(). In my logic, synchronize(dummyproc) must have NO effect on the parent thread.
And it have.
I can imagine (and accept) that synchronize(Graphicproc) have effect on parent thread but synchronize(dummyproc), that i can not understand (and accept).
PS : Im busy to upgrade from 2.6.2 to 2.7.1 (what a hell to do a upgrade !) and gonna try queue(dummyproc) instead and say the result.
Thanks


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Synchronize(dummyproc) with Linux.

Sven Barth-2
Am 02.05.2013 13:25, schrieb Fred van Stappen:
> that is the slowest system (by a big margin) I have
> available.

Im very interested by the result.
But i continue to think there is something strange with synchronize(). In my logic, synchronize(dummyproc) must have NO effect on the parent thread.
And it have.
It seems that you didn't read what I wrote. Synchronize always blocks until the given method was executed by the main thread. So even if your method is empty there will be a delay until the mainthread processes the synchronized method. And the more busy the main thread is (e.g. updating the GUI) the more time it takes until it can process a synchronized message. Also multiple Synchronize events will be executed in multiple runs of CheckSynchronize runs, because the "queue" in pre-2.7.1 can only hold one element. In 2.7.1 the queue can hold multiple methods enqueue by Synchronize and Queue.

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
@ sven : Many thanks for answer ( and of course i had read and study deeply your clear earlier topic ).

>So even if your method is empty there will be a delay until the mainthread processes the synchronized method.

Ok, difficult to understand that a empty method gives a delay, but if it is a axiom, nothing to understand, i have to accept it . Many thanks.

Hope gonna have better result with queue() in fpc 2.7.1. (But what a nightwear to do a upgrade of fpc, i tremble to the idea of having to do it and the loooooots of time it gonna takes me.

But when you love, you do not count. ;)
Many thanks

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

Michael Van Canneyt


On Thu, 2 May 2013, Fred van Stappen wrote:

> @ sven : Many thanks for answer ( and of course i had read and study deeply your clear earlier topic ).
>
> >So even if your method is empty there will be a delay until the mainthread processes the synchronized method.
>
> Ok, difficult to understand that a empty method gives a delay, but if it is a axiom, nothing to understand, i have to accept it . Many thanks.

This is not an axiom, but simply a consequence of the definition of Synchronize().

Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it.

Nowhere does it state that this will be done immediatly.
The code in the main thread is responsible for checking at regular intervals if a procedure was scheduled, and if so, execute it.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs
> Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it.

Ok, i understand that, but if that procedure is dummy, i do understand why it takes a delay.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

Sven Barth-2

Am 02.05.2013 15:24 schrieb "Fred van Stappen" <[hidden email]>:
>
> > Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it.
>
> Ok, i understand that, but if that procedure is dummy, i do understand why it takes a delay.

The Synchronize code can not know that the method you passed is an empty one, so it's handled like every other method. And even if the compiler could know that it is an empty one it could not judge what Synchronize is doing with it (especially since Synchronize and the execution code in CheckSynchronize is very loosely coupled). Also it is consistent that an empty method is handled the same as a non-empty one.

And again: the delay until Synchronize returns is not only dependant on the runtime of the method, but also on the frequency in which the main thread calls CheckSynchronize in which the method will finally be executed.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: Synchronize(dummyproc) with Linux.

fredvs

> > Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it.
>
> Ok, i understand that, but if that procedure is dummy, i do understand why it takes a delay.
The Synchronize code can not know that the method you passed is an empty one, so it's handled like every other method. And even if the compiler could know that it is an empty one it could not judge what Synchronize is doing with it (especially since Synchronize and the execution code in CheckSynchronize is very loosely coupled). Also it is consistent that an empty method is handled the same as a non-empty one.
And again: the delay until Synchronize returns is not only dependant on the runtime of the method, but also on the frequency in which the main thread calls CheckSynchronize in which the method will finally be executed.
Regards,
Sven
________________________________________________________________

Yep, Sven, that is a clear explanation.
Now, ok, i catch it.
Many thanks. ( and i gonna finally sleep good this night ). ;)

PS : Im a totally FPC-addicted and i like that ;).


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: AT-SPI fpc compatible ?

fredvs
In reply to this post by Michael Van Canneyt
>Hello.
>I want add access to AT-SPI interface.
> http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface

>Does it exist a pascal header for that ?
>Does anybody know how to do it, via fpc, not lcl ?
>Thanks.

Toc, toc, toc, is there anybody here ?
Nobody have some experience with AT-SPI and FPC ?
For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA.
Could somebody help me to use AT_SPI with pure fpc (no LCL) ?
Thanks.

PS : It is a shame that FPC does not care about assistive technology.

Many thanks.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: AT-SPI fpc compatible ?

Michael Van Canneyt


On Wed, 8 May 2013, Fred van Stappen wrote:

>
> >Hello.
> >I want add access to AT-SPI interface.
> > http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface
>
> >Does it exist a pascal header for that ?
> >Does anybody know how to do it, via fpc, not lcl ?
> >Thanks.
> Toc, toc, toc, is there anybody here ?
> Nobody have some experience with AT-SPI and FPC ?
> For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA.
> Could somebody help me to use AT_SPI with pure fpc (no LCL) ?
> Thanks.
> PS : It is a shame that FPC does not care about assistive technology.

Why do you say that ? As far as I can see, AT-SPI is a library like any other.

There are many libraries out there. We do not have the manpower to translate
headers for all libraries. So it has nothing to do with 'caring'. It is a question
of available manpower.

If it was not translated it means no-one had the need for it.
To my knowledge, you are the first to ask about it.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: AT-SPI fpc compatible ?

Michael Schnell
In reply to this post by fredvs
On 05/08/2013 10:07 AM, Fred van Stappen wrote:
> Toc, toc, toc, is there anybody here ?

You hitchhiked a running forum thread.

Nobody likes to answer on such indecent posts.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: AT-SPI fpc compatible ?

Sven Barth-2
In reply to this post by fredvs
Am 08.05.2013 10:07, schrieb Fred van Stappen:
>Hello.
>I want add access to AT-SPI interface.
> http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface

>Does it exist a pascal header for that ?
>Does anybody know how to do it, via fpc, not lcl ?
>Thanks.

Toc, toc, toc, is there anybody here ?
It might help if you wouldn't start a new question by answering to a mail in an existing thread. I needed to search your first mail first, because it wasn't listed on the top level of the threads and you didn't directly answer to your previous message either...
Nobody have some experience with AT-SPI and FPC ?
For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA.
Could somebody help me to use AT_SPI with pure fpc (no LCL) ?
Thanks.

PS : It is a shame that FPC does not care about assistive technology.
It is not about not caring. You must not forget that FPC as well as Lazarus are developed in the free time of us developers. So it's more likely that things are implemented that are interesting to the devs. If you want to change something about missing support for assistive technology: patches are welcome (I know that this may sound harsh, but this is how it works). Or put up a bounty...

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123