[erlang-questions] Real time audio transcoding with a port driver

[Dan Bender]

I checked with timer:tc/3 and calling a port driver with encode or decode
takes 4ms:

timer:tc(?MODULE, command, [Port, encode, Binary])
command(Port, Type, Binary) ->
    port_control(Port, Type, Binary).

Is this the correct way to measure it?
How do I choose how much to bump reductions assuming that it takes 4ms to
run?
Is it reasonable to assume that a more modern and powerful CPU will result
with 1/10 time which will be < 1 ms?

I'm trying to understand if I can use NIF today and take advantage of dirty
schedulers and native processes in a year or two.




On Tue, Jul 2, 2013 at 1:16 PM, Kenneth Lundin <kenneth.lundin@REDACTED>wrote:

> Hi Max,
>
> I don't know why you are thinking that this will work better in R15 than
> in R16?
> Can you point to any specific change in R16 that causes problems?
>
> It has always been a bad idea to execute for a long time (before returning
> to the Erlang scheduler) inside a NIF, BIF or linked in driver.
>
> In R16B01 some BIFs and NIFs which potentially could execute for a long
> time (based on the size of their input) have been made interruptible. More
> specifically this concens the BIF term_to_binary and
> the crypto NIFs which handle stream input.
>
> /Kenneth, Erlang/OTP, Ericsson
>
>
> On Tue, Jul 2, 2013 at 11:17 AM, Max Lapshin <max.lapshin@REDACTED>wrote:
>
>> It is also possible to revert to R15, but in any case if NIF will
>> block scheduler, you will have problems with managing hunders of
>> streams.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130702/b4e1df58/attachment.htm>