Pipe vs Memory buffer.

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Pipe vs Memory buffer.

noreply
On Sun, January 29, 2017 6:04 am, José Mejuto wrote:

> El 28/01/2017 a las 13:32, fredvs escribió:
>
>
>> TOpusFileCallbacks = record
>> read: op_read_func;
>> seek: op_seek_func;
>> tell: op_tell_func;
>> close: op_close_func;
>> end;
>>
>> This does not work:
>>
>>
>> HandleOP := op_test_callbacks(pointer(InPipe),op_callbacks,
>> BufferURL[0],
>> PipeBufferSize, err);
>>
>>
>
> Hello,
>
>
> As you need to use records you should specify {$PACKRECORDS C} or you
> could get a different record layout than C expects.
>
> --

Doesn't some C compilers pack records differently, so packrecords is only
compatiable with GNU c compiler but some other compiler could do it
differently? Sorry I don't know
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Pipe vs Memory buffer.

Sven Barth-2

Am 29.01.2017 23:33 schrieb "Lars" <[hidden email]>:
>
> On Sun, January 29, 2017 6:04 am, José Mejuto wrote:
> > El 28/01/2017 a las 13:32, fredvs escribió:
> >
> >
> >> TOpusFileCallbacks = record
> >> read: op_read_func;
> >> seek: op_seek_func;
> >> tell: op_tell_func;
> >> close: op_close_func;
> >> end;
> >>
> >> This does not work:
> >>
> >>
> >> HandleOP := op_test_callbacks(pointer(InPipe),op_callbacks,
> >> BufferURL[0],
> >> PipeBufferSize, err);
> >>
> >>
> >
> > Hello,
> >
> >
> > As you need to use records you should specify {$PACKRECORDS C} or you
> > could get a different record layout than C expects.
> >
> > --
>
> Doesn't some C compilers pack records differently, so packrecords is only
> compatiable with GNU c compiler but some other compiler could do it
> differently? Sorry I don't know

FPC adheres to the system's ABI. So packrecords c might result in different records on e.g. Linux or Windows or even the same OS on different platforms.
So as long as the used C compiler adheres to the ABI as well, there shouldn't be any problem.

Regards,
Sven


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

Re: Pipe vs Memory buffer.

noreply
In reply to this post by fredvs
On Sun, January 29, 2017 4:45 am, fredvs wrote:

> Hello Lars.
>
>
> Thanks for your brilliant light.
>
>
>> (and can you look into the actual source code of opus or is this closed
>>  source?)
>
> ==> https://github.com/xiph/opus
>


Well the function you were using with a buffer is here:

https://github.com/xiph/opusfile/search?utf8=%E2%9C%93&q=op_test_memory

in src/opusfile.c

OggOpusFile *op_test_memory(const unsigned char *_data,size_t _size,
 int *_error){
    OpusFileCallbacks cb;
    return
op_test_close_on_failure(op_mem_stream_create(&cb,_data,_size),&cb,
   _error);
}

So it calls op_mem_stream_create which is:
https://github.com/xiph/opusfile/search?utf8=%E2%9C%93&q=op_mem_stream_create&type=Code

in src/stream.c

void *op_mem_stream_create(OpusFileCallbacks *_cb,
 const unsigned char *_data,size_t _size){
  OpusMemStream *stream;
  if(_size>OP_MEM_SIZE_MAX)return NULL;
  stream=(OpusMemStream *)_ogg_malloc(sizeof(*stream));
  if(stream!=NULL){
    *_cb=*&OP_MEM_CALLBACKS;
    stream->data=_data;
    stream->size=_size;
    stream->pos=0;
  }
  return stream;
}


Thanks to github's cool web gui you can find code pretty fast and share
where code is with developers, compared to if it was on your hard drive
you could not "share your hard drive" unless you were on emule or vnc ;-)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Pipe vs Memory buffer.

fredvs
Hello Lars.

Many thanks to spent your time for us.

But after lot of test and re-test, my conclusion is:

op_open_memory() is buggy.

It looses the pointer assigned to the input-buffer of bytes.

And when using op_read() it points to nil in place of buffer-in.

Voila.

(But maybe I m wrong...).

Fre;D

Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Pipe vs Memory buffer.

fredvs
> op_open_memory() is buggy.
> (But maybe I m wrong...).

Yes I was wrong.

Opus needs a bigger buffer than mp3, increasing the size fixed it.

It works, sound is perfect from a https too.
Only remain a problem: after 10 seconds of playing, op_read_float() does not give output.

I must study deeper how pipes work.

But this is a detail, the solution will follow fast.

Many thanks to everybody for your help.

Fre;D
Many thanks ;-)
12