Re: Converting to PFile, Timers, Threads

[Christian Reiniger <warewolf@mayn.de>]

Peter Burns wrote:
>CONVERTING TO PFILE
>
>I eventually plan to support placing samples in pak files.
>What do I need to do to convert convert from the standard
>file functions to the ones in PFile? Is it something as easy
>as replacing fread with ppfRead ?

Yup. At least basically. You have to include <PenguinPlay/PenguinFile.h> of
course, and use ppfFILE instead of FILE etc.
The only thing where PFile really goes its own way is for flags (access
permissions etc). Check PenguinFile.h for the details (it's quite simple).

In what way do you want to use it? Let the User specify some URL to open?

>I have been starting to using libaudiofile to load samples.
>It seems to be very portable. I only had to add guards for
>unistd.h and a few other minor things to get it to compile
>under windows. I'd prefer to leave it to libaudiofile to
>handle the samples but if it would be possible to get it
>to work with pak files without modifying it.

I don't know how it handles this stuff. Does it leave the file
opening/reading to the user or does it do that itself (the it's impossible)?

BTW you should wait with switching to PFile. It will take some more time
until it's really useable.

>TIMERS
>
>Are there any utilities for setting timers in penguinplay?

Not yet.

>I think a timer class might be very useful.
>Whats the best way to implement a millisecond timeout
>in unix? I've been using setitimer.  The one pitfall is
>that each process has only one timer. You have to be
>careful if your using threads since threads share the timer
>and you need to be careful that the right thread gets the
>right signal.

That means we need some code controlling that.

>THREADS
>
>I have been using a separate thread to mix the
>samples for /dev/dsp and  esound. This is done so that
>it can be treated in the same manner as /dev/sequencer
>and directsound.
>
>Would it be better to instead fork a separate process for this and
>communicate via a pipe or shared memory or something?

Threads should be fine

>Some graphics libraries aren't thread safe.
>Gtk seems to be okay with it as long
>as only one thread handles the interface. Qt seems
>to have problems with threads.

As long as you don't access it with two threads simultaneously things
should be ok.

>FIRST DATA - CONFIDENTIAL COMMUNICATION
>===========================================
>This e-mail and any files transmitted with it are confidential and are
>intended solely for the use of the individual or entity to whom it is
>addressed.  If you are not the intended recipient be advised that you have

Huh?


	Christian
--

Drive A: not responding...Formatting C: instead