Hello.

In Unix systems File Descriptor can be created with fpPipe(FDInput, FDOutput).
Then FDInput/FDOutput may be used as file descriptors. Ok, perfect.

But fpPipe is part of BaseUnix/Unix...

So the question is:

How to create such of File Descriptor with Windows?...

Many thanks.

Fre;D

1) - Use fpPipe in BaseUnix/Unix to create a fifo.
2) - Create a THandleStream using the returned input value of fpPipe.
3) - Use mpg123_open_fd from the output value from fpPipe
4) - Use an instance of TfpHttpClient.Get(YourURL, AHandleStream) to retrieve the stream.

-----
Many thanks ;-)

See unit pipes, there is a platform-independennt call:
Function CreatePipeHandles (Var Inhandle,OutHandle : THandle; APipeBufferSize : Cardinal = 1024) : Boolean;

There is a second function which creates TStreams descendents.

Michael.

APipeBufferSize : Cardinal = 1024) : Boolean;

>There is a second function which creates TStreams descendents. >Michael.

Ooops, so fast and so good !
I will try it now.
Write you later.

Many thanks.

Fre;D

-----
Many thanks ;-)

Hello.

Added Pipes in uses section.

Changed => AssignPipe(InHandle, FOutHandle);
Into => CreatePipeHandles (InHandle, FOutHandle, PipeBufferSize);
Then in code =>
var
  Http: TFPHTTPClient;
  Output: THandleStream = nil;
  URL: String;
begin
  Http := TFPHTTPClient.Create(nil);
  Output := THandleStream.Create(FOutHandle);
  URL := FWantedURL;
   Http.RequestHeaders.Clear;
  Http.Get(URL, Output);

=> Perfect for Linux, compiles + web procedure runs perfectly (like using fpPipe).

In Windows, same code compiles ok but when trying to run the web procedure, Program gives that error =>

An unespected error occurred File not open

? ;-(

Fre;D

-----
Many thanks ;-)

Re-hello.

Tried with this too =>

Change =>  Output: THandleStream = nil;
into  => Output: TOutputPipeStream = nil;

and

Change => Output := THandleStream.Create(FOutHandle);
into =>   Output:=TOutputPipeStream.Create (FOutHandle);

=> Compiles + works perfect in Linux ;-)

=> Compiles ok but does not work on Windows ;-(
(file not open)

?

Thanks.

Fred;D

-----
Many thanks ;-)

What do you do with the inHandle ?

Michael.

What do you do with the inHandle ? Michael.

It is used by mp123 mp3-decoder library.

=>function mpg123_open_fd(mph: Tmpg123_handle; fd: integer);
fp (file descriptor) := InHandle ;

It seems that InHandle as file descriptor does not work on Windows. But in *nix system, it works.

-----
Many thanks ;-)

Check for writeln's in the htmlthread unit you added.

It should work, because TProcess relies on this function to do it's job. However, pipes work differently from normal file descriptors.

Michael.

@ Andrew

Check for writeln's in the htmlthread unit you added.

Hum, i did not add htmlthread unit (only fphttpclient and pipes). What do you mean ?

@ Martin

It should work, because TProcess relies on this function to do it's job.

Yes, maybe, but it does not work ;-(
Could it be a problem of conversion into file descriptor ? It seems that fle descriptor are posix and unix only... Microsoft added support to for open/write, but renamed the (non-C-standard) functions to _open/_write.

Aaargh, Microsoft, you are so lonely....

Fre;D

-----
Many thanks ;-)

Check for writeln's in the htmlthread unit you added.

Oops, i think i get it (sorry it is Sunday). ;-(

- CreatePipeHandles (InHandle,OutHandle, PipeBufferSize);
- Writeln('Input Handle = ' + inttostr(InHandle) + ' Output Handle = ' + inttostr(OutHandle));
=> Linux => Input Handle = 3 Output Handle = 4
=> Windows => Input Handle = 212 Output Handle = 216

- Output:=TOutputPipeStream.Create (OutHandle);
- if Output = nil then  writeln('===> NO Pipe Stream created.') else
- writeln('===> Output Pipe Stream created.');
=> Linux + Windows => ===> Output Pipe Stream created.
-  err := mpg123_open_fd(MyMPHandle, InHandle);
- if err = 0 then writeln('===> mpg123_open_fd => ok.') else
       writeln('===> mpg123_open_fd NOT ok.') ;
=> Linux + Windows => mpg123_open_fd => ok.
- err := mpg123_read(MyMPHandle, blabla);
- writeln('===> mpg123_read error => ' + inttostr(err)) ;
=> Linux => mpg123_read error => 0 => no error
=> Windows => mpg123_read error => 12 => Invalid RVA mode

Ooops, what is RVA mode?...

Thanks.

Fred.

-----
Many thanks ;-)

Yep, there is a answer from mpg123 creator in forum list ;-) =>

Ok, conclusion of the story => fpc is perfect and not the guilty ;-)

Now, i have to make that descriptors compatible. ;-(

Many thanks.

Fre;D

-----
Many thanks ;-)

Hello.

Sorry to sorry to bother you with that file descriptors again... ;-(

There are some answers there on mpg123 forum.
They explain that "simple stdin/stdout file descriptors would work." Of course all what they explained is in C ;-(

OK, but how can i use "simple stdin/stdout file descriptors" in Pascal ? What is the code to retrieve that stdin/stdout file descriptors in Windows?

Many thanks.

Fre;D

-----
Many thanks ;-)

What in unix is used as filedescriptor is in general in windows used as handle (filehandle/sockethandle)

Googling for "windows msdn stdin" resulted in:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231%28v=vs.85%29.aspx

I've no clue why a lib should need this (and if a non console app would have any)

BTW, back to your original question, I looked at the docs for mpg123_open_fd() but it absolutely clueless about the second argument

Marc

They are available in default variables in the system unit: StdInputHandle,StdOutputHandle,StdErrHandle

Michael.

I've been thinking that for your purposes you could use mpg123_replace_reader_handle
http://www.mpg123.de/api/group__mpg123__lowio.shtml#ga61a125c56f2aab9590a4b1a29194dc10

and
mpg123_open_handle
http://www.mpg123.de/api/group__mpg123__input.shtml#gaadda450ea307f88589cb77ffda0754ab

Then you could do
mpg123_open_handle(mpg, Output); //Output is a TStream descendant

and the functions you supply with mpg123_replace_reader_handle can just read directly from the TStream. Then you don't have to rely on anything on each OS other than some TStream descendant can read the file you want to play.

Andrew

PS I noticed these functions don't exist yet in your mpg123 bindings. <http://www.mpg123.de/api/group__mpg123__input.shtml#gaadda450ea307f88589cb77ffda0754ab>

@ Michael =>

They are available in default variables in the system unit: StdInputHandle,StdOutputHandle,StdErrHandle

Yep, good to know, thank-you ;-)
Sadly, it does not solve the problem... ;-(

@ Andrew

you could use mpg123_replace_reader_handle and mpg123_open_handle

Ok, good idea, i will study it... ;-)

Hum,... by the way,.. if,.. fortuitously (and by chance) you have already try it with your PulseAudio wrapper, could it be possible to show some code ?

Many thanks.

Fre;D

PS: Why everything must be so compilcated with Windows ?

-----
Many thanks ;-)

@ Andrew Hum,... by the way,.. if,.. fortuitously (and by chance) you have already try it with your PulseAudio wrapper, could it be possible to show some code ?

Ooops, i just check my mail now and =>...
Andrew, you are a Angel ;-)

Tetra billion of thanks.

PS: I will test it and give you news by email.

Thanks to everybody.

Fre;D

-----
Many thanks ;-)

fredvs wrote

PS: Why everything must be so compilcated with Windows ?

It's not if developers wouldn't decide to make their libraries so *nix centric...

Regards,
Sven

It's not if developers wouldn't decide to make their libraries so *nix

centric...

Or when they will decide to develop their libraries with something else than C, that gives them compilers choice that are not compatible together (a library compiled with CGwin is not compatible with one compiled with one compiled with Visual Studio.)

The good idea will be to choose for a compiler more cross-platform... like fpc. ;-)

Fre;D

-----
Many thanks ;-)

I don't understand this remark ?
What is so *nix centric about a file descriptor ?

Michael.

IMHO:
The call is needed because unlike unix, stdinput, output and error file descriptors are not equal to 0 1 2. So you need a call to retrieve the actual value.

The system unit calls these functions and stores the result in the variables I mentioned.

Michael.

centric...

I don't understand this remark ? What is so *nix centric about a file descriptor ?

Per se nothing. But if that can only handle StdIO pseudo handles in Windows then I'd definitely call that *nix-centric or at least not fully useable on Windows. I personally would have declared a platform specific handle type like we have in our RTL and then would have used the OS specific routines to handle them. Also I assume that on Win64 that fd type used by mpg123 is still int while a Handle there is a 64-bit value (I didn't check the code so this is only an assumption) making it even more incompatible with the Windows routines...

Regards,
Sven

Hello.

For info, here answer from mpg123 creator =>
______________________________________________________

4) Assisgn input pipe stream => mpg123_open_fd(MyMPHandle,InHandle); => Crash on Windows, OK on Linux.

I don't have my head wrapped around the pascal bindings, but are you handing your pipe handle to mpg123_open_fd() without change? What should the mpg123 C code, expecting a C library file descriptor, do with your handle created in Pascal/Delphi with whatever runtime in the background? File descriptors may be compatible, but don't have to.

If that is really the case here, it would be best not to include mpg123_open_fd() in a Pascal binding at all, or altenatively, make it a wrapper that actually used mpg123_open_handle() and handles the I/O conversion itself.

As I said, I didn't look closer, but it appears to me that you're just lucky on Linux since Pascal and C share more runtime environment.

Alrighty then,

Thomas

____________________________________________________

-----
Many thanks ;-)