hanks toni,
But as you see i am not writing anything to file but actual dsp h/w which
is very fast as compared disk access.. my file_put_frame() writes directly
to dsp internal memory.. but due to limited CPU frequency(125MHz) i cant
scale up my calls to more than 4.. we want develop 32 channel SIP to analog
Gateway.out of these calls ,16 will be using alternate audio which we have
done successfully. 16 we want to manage using conference bridge. here idea
is
- we create 16 wave players and writers at boot time.
2)if channel is between 1 to 16 we don't create stream so no conference
port will be created.(and audio will be managed by application)
- if its between 17 to 32 then will create stream and will connect them to
wave writer and player for two way speech.
but by design of PJMedia conference bridge .if it's master D driven clock
(null audio) ,then all speech switching ,RTP encoding & decoding is done by
get_frame() of conference bridge only.. unlike sound device which has delay
buffer for capture interface ..
this get_frame() function which is called by clock thread alone takes 70%
CPU for 4 calls.
so just wanted a solution that can scale up my calls. but still cant
understand ,what part of get_frame() is CPU intensive ??
Regards,,
Kiran Bhosale
On Sun, Mar 19, 2017 at 5:03 PM, Toni Rutar buldozer@aufbix.org wrote:
Hi,
If your issue is the same as mine was (writer taking too long in
processing of 'file_put_frame' and thus disturbing the audio flow) then you
could try what I did - do the actual writing/processing in a separate
thread. For that I created a FIFO buffer, which gets filled in the
'file_put_frame', while emptying of the buffer (writing to disk in my case)
is done in a separate thread (buffer and thread are initialized in the
'writer_port_create' and cleaned up in the 'file_on_destroy'. You can check
the attached mp3_writer.c to see my implementation. Check the parts which
get compiled if WRITER_USES_THREAD is defined.
Greets, Toni
hanks toni,
But as you see i am not writing anything to file but actual dsp h/w which
is very fast as compared disk access.. my file_put_frame() writes directly
to dsp internal memory.. but due to limited CPU frequency(125MHz) i cant
scale up my calls to more than 4.. we want develop 32 channel SIP to analog
Gateway.out of these calls ,16 will be using alternate audio which we have
done successfully. 16 we want to manage using conference bridge. here idea
is
1) we create 16 wave players and writers at boot time.
2)if channel is between 1 to 16 we don't create stream so no conference
port will be created.(and audio will be managed by application)
3) if its between 17 to 32 then will create stream and will connect them to
wave writer and player for two way speech.
but by design of PJMedia conference bridge .if it's master D driven clock
(null audio) ,then all speech switching ,RTP encoding & decoding is done by
get_frame() of conference bridge only.. unlike sound device which has delay
buffer for capture interface ..
this get_frame() function which is called by clock thread alone takes 70%
CPU for 4 calls.
so just wanted a solution that can scale up my calls. but still cant
understand ,what part of get_frame() is CPU intensive ??
Regards,,
Kiran Bhosale
On Sun, Mar 19, 2017 at 5:03 PM, Toni Rutar <buldozer@aufbix.org> wrote:
> Hi,
>
>
> If your issue is the same as mine was (writer taking too long in
> processing of 'file_put_frame' and thus disturbing the audio flow) then you
> could try what I did - do the actual writing/processing in a separate
> thread. For that I created a FIFO buffer, which gets filled in the
> 'file_put_frame', while emptying of the buffer (writing to disk in my case)
> is done in a separate thread (buffer and thread are initialized in the
> 'writer_port_create' and cleaned up in the 'file_on_destroy'. You can check
> the attached mp3_writer.c to see my implementation. Check the parts which
> get compiled if WRITER_USES_THREAD is defined.
>
>
> Greets, Toni
