IMO this is the correct way...
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi Jerome!
I've asked information about how common is that condition because I had
no problem here initializing the audio devices of the same soundcard
with different framesizes.
I've made lots of test calls using my onboard soundcard on Windows with
some variety of framesize scenarios, like: 40ms on TX and 20ms on RX;
30ms on both paths (iLBC's "mode" parameter config), etc.
Now, considering that I can't rely on anything, I suppose the best
choice is to get back the audio devices initialization blocked (i.e.
hardcoded) to work with the framesize resulting of 20ms packetization
for both paths.
This will avoid lots of changes and the inevitable demanded tests.
We initialize incoming and outcoming audio paths to work always with
framesize of 160 shorts (or 320 if we work at 16 KHz) - that is the way
it used to work before the patch I've sent, and create buffer adaption
routines to both paths oh "phmedia-audio.c" in order to process the
incoming and outgoing data accordingly.
What do you think ?
Thanks and best regards,
Mauro.
jerome wagner escreveu:
Hello,
basicall, from what I remember (and from what I understand of
your question), you can't rely on anything.
MIC and SPK accepted framesizes would typically be the same if
you work on the same soundcard.
but as soon as you work with different devices (MIC integrated
on your webcam & SPK on your standard soundcard) accepted
framesizes will be different.
MacOSX API has an integrated resampler in their sound API that
can resample things for you from the "physical" framesizes (hardware
driven) to the "logical" framesizes (those available via software
invocation)
you have no other choice than go down a "preferred" list and
ask
the devices if they accept what you would like. You might end up with
different framesizes on MIC and SPK.
Once the negociation with MIC and SPK is done, you have to
propagate the choice in the audio graph so the every every component
interface has a known framesize.
I hope this helps
Jerome
2009/7/28 Mauro Sergio Ferreira Brasil <mauro.bra...@tqi.com.br>
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
<mauro.bra...@tqi.com.br>
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 |
| + mauro.bra...@tqi.com.br |
| : 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 |
| + mauro.bra...@tqi.com.br |
| : www.tqi.com.br |
| ( + 55 (34)3291-1700 |
| ( + 55 (34)9971-2572 |
_______________________________________________
QuteCom-dev mailing list
QuteCom-dev@lists.qutecom.org
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
--
| At.,
|
 |
| Technology
and Quality
on Information |
| Mauro Sérgio
Ferreira Brasil |
| Coordenador
de Projetos e
Analista de Sistemas |
| + mauro.bra...@tqi.com.br |
| : 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 |
| + mauro.bra...@tqi.com.br |
| : www.tqi.com.br |
| ( + 55 (34)3291-1700 |
| ( + 55 (34)9971-2572 |
|
