Hi Jerome!
Thanks for the graphs!
They are extremely enlightening indeed.
Just to clear things up, do you know whether the abnormal condition we
need to deal is :
1- Sometimes, input and output audio devices can't operate with
different framesizes; or
2- Sometimes, input or output audio devices can't operate with
framesizes different of the resulting 20ms packetization ?
I think the only condition we need to consider is given by item 1, but
I need to be sure that item 2 isn't possible as well.
Do you have conditions to indicate the limitations we need to consider
(just 1, just 2, or both) ?
Can you tell me how common is this condition ?
Thanks and best regards,
Mauro.
jerome wagner escreveu:
Hello,
Just in case it helps and before it gets lost, I digged those
diagrams out of hard drive. They come from an analysis I did on the
phapi audioflows about 1 year ago. They clarified for me some of the
code entry points.
I can send the original .vsd if needed.
Jerome
2009/7/27 Mauro Sergio Ferreira Brasil <[email protected]>
Hi Vadim!
I was not aware of such condition.
I understand and agree with you that, considering this, we need to make
the necessary changes to handle this difference outside the scope of
audio device initialization/manipulation.
So, when you said that they are "unable to work with different
framesize" you mean that the output and input audio devices can't
operate at different framesizes (like input at 20ms and output at
30ms), right ?
Anyway, do you have any suggestion on where to place the buffer
adaption codes to outgoing and incoming audio paths ?
Making some tests, I perceived audio traffic only through methods
"ph_audio_play_cbk" (used to play network incoming audio) and
"ph_audio_rec_cbk" (used to send audio device audio to network).
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Mauro,
I've been thinking some more about this packetization issue...
And i think that there is no need to have 2 different framesizes for
the simply reason that sometimes we have
audio devices that are simply unable to work with different framesize.
The framesize adaptation should be done externally and not
xxx_stream_yyy routines IMO
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi
Vadim!
The patch with changes as requested by you to not create dependency
from "eXosip" with "phapi" follows attached.
It was built over trunk version retrieved yesterday.
The only point I think will demand some consideration is regarding the
changes on file "phmedia-portaudio.c" so the audio devices could be
configured with different numbers of frames per buffer for incoming and
outgoing paths.
In order to maintain the "XXX_stream_open" method signature, I choose
to still make use of "framesize" input parameter adding comments on
"open_audio_device" method (from "phmedia-audio.c" file), and inside
"pa_stream_open" to indicate the dependency between the framesize
informed on "audio_stream_open" call and the other calculated inside
"pa_stream_open" method.
Gettting things short, I inform the incoming audio framesize using the
current available parameter, and calculate the outgoing framesize
using: 1- the incoming framesize; 2- the incoming packetization and
outgoing packetization given by "phastream_t" structure. Using an
inverse logic, I've applied the incoming framesize on output device
creation and vice-versa.
In fact, IMHO the desirable approach would be to change
"XXX_stream_open" signature to have two framesize parameters
(indicating differently the framesize for input and output paths) what
will lead to changes on all "phmedia-XXX" implementations, like
portaudio, alsa, etc.
This approach is desirable because will force the signature changing
for all implementations and the respective care with the internal
changes demanded.
Anyway, I choose the easy way what caused some dependency between the
"phmedia-audio.c" and "phmedia-portaudio.c" files that were not
replicated by me to other implementations besides portaudio that is the
one we use here.
Please let me know if you have any disagreements with that.
I'll be waiting some reply from you.
Thanks and best regards,
--
| At.,
|
![]() |
| Technology
and Quality
on Information |
| Mauro Sérgio
Ferreira Brasil |
| Coordenador
de Projetos e
Analista de Sistemas |
| + [email protected] |
| : www.tqi.com.br |
| ( + 55 (34)3291-1700 |
| ( + 55 (34)9971-2572 |
--
| At.,
|
![]() |
| Technology
and Quality
on Information |
| Mauro Sérgio
Ferreira Brasil |
| Coordenador
de Projetos e
Analista de Sistemas |
| + [email protected] |
| : www.tqi.com.br |
| ( + 55 (34)3291-1700 |
| ( + 55 (34)9971-2572 |
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
--
TQI - Technology and Quality on Information
| At.,
|
 |
| Technology and Quality
on Information |
| Mauro Sérgio Ferreira Brasil |
| Coordenador de Projetos e
Analista de Sistemas |
| + [email protected] |
| :
www.tqi.com.br |
| ( + 55
(34)3291-1700 |
| ( + 55
(34)9971-2572 |
|
