Title: TQI - Technology and Quality on Information
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 |
--
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 |
|
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
