Hi,
timing is provided by the write and read source.
For a 480 bytes of pcm data, the speaker system is
guaranteed to take 30ms
to play it - which is your timing.
Similarily, to read 480 bytes, that takes 30ms. ((Assuming
8khz audio))
Derek.
On Tue, 15 Aug 2006, Paul Rolland wrote:
> Euh... Question : what is providing timing to a patch ?
It seems to be
> a quite active loop doing read on Source and write to
Sink, but I can't find
> any delay and/or related stuff....
>
> Is this the reason of my problem ? A WAV file can
provide bytes faster than
> a sound interface ??? If so, would adding a delay at
the read time be a
> "valid" solution ?
>
> Regards,
> Paul
>
> Paul Rolland, rol(at)as2917.net
> ex-AS2917 Network administrator and Peering Coordinator
>
> --
>
> Please no HTML, I'm not a browser - Pas d'HTML, je ne
suis pas un navigateur
> "Some people dream of success... while others
wake up and work hard at it"
>
> "I worry about my child and the Internet all the
time, even though she's too
> young to have logged on yet. Here's what I worry
about. I worry that 10 or 15
> years from now, she will come to me and say 'Daddy,
where were you when they
> took freedom of the press away from the
Internet?'"
> --Mike Godwin, Electronic Frontier Foundation
>
>
> > -----Original Message-----
> > From: openh323-admin openh323.org
> > [mailto:openh323-adminopenh323.org] On Behalf Of
Paul Rolland
> > Sent: Tuesday, August 15, 2006 6:37 PM
> > To: openh323openh323.org
> > Cc: rolas2917.net
> > Subject: RE: [OpenH323]Opal - Some questions...
> >
> > Hello,
> >
> > Please, help me, I'm getting desesperate trying
to figure this out...
> >
> > Problem description : when using a WAV file as a
source and
> > as a sink, the
> > transfer seems to be correct but last only one
half of the real source
> > file duration... When connecting the WAV source to
a real G.711 sink,
> > the sound is really going too fast, but it seems
that some
> > parts are lost,
> > and some are correct...
> >
> > Some more details...
> > 1 - I've included the sound_wav module I'm using
as a replacement for
> > sound_oss and sound_alsa in PWLib,
> >
> > 2 - I've added even more PTRACE inside Opal to
try to
> > understand, and here
> > are some data I collected from the caller...
I've removed
> > some traces and
> > kept only the ones related to the patch from
PCM-16 to G.711.
> > The one that is interesting is :
> > 0:12.452 Media Patc...ch:80abcd8
mediastrm.cxx(706) Stream
> > OpalRawMediaStream::ReadData(..., 320, ...)
> > 0:12.462 Media Patc...ch:80abcd8
mediastrm.cxx(706) Stream
> > OpalRawMediaStream::ReadData(..., 320, ...)
> > 0:12.472 Media Patc...ch:80abcd8
mediastrm.cxx(706) Stream
> > OpalRawMediaStream::ReadData(..., 320, ...)
> >
> > Basically, we are reading 320 bytes out of the
WAV file
> > every 10 ms,
> > then converting them to 160 bytes for G.711,
which seems
> > to indicate
> > that these bytes are worth 10ms of sound...
> >
> > Problem : the input WAV file is a RIFF
(little-endian)
> > data, WAVE audio,
> > Microsoft PCM, 16 bit, mono 8000 Hz, 15s worth
of audio,
> > and 220K long,
> > which makes roughly 160 bytes for 10ms !
> >
> > So, reading 320 bytes for 10ms looks deeply
wrong...
> >
> > Could someone point out what is wrong ? The input
file format
> > ? The conversion
> > ?
> >
> > Regards,
> > Paul
> >
> > Paul Rolland, rol(at)as2917.net
> > ex-AS2917 Network administrator and Peering
Coordinator
> >
> > --
> >
> > Please no HTML, I'm not a browser - Pas d'HTML,
je ne suis
> > pas un navigateur
> > "Some people dream of success... while
others wake up and
> > work hard at it"
> >
> > "I worry about my child and the Internet all
the time, even
> > though she's too
> > young to have logged on yet. Here's what I worry
about. I
> > worry that 10 or 15
> > years from now, she will come to me and say
'Daddy, where
> > were you when they
> > took freedom of the press away from the
Internet?'"
> > --Mike Godwin, Electronic Frontier Foundation
> >
> >
> > > -----Original Message-----
> > > From: openh323-adminopenh323.org
> > > [mailto:openh323-adminopenh323.org] On Behalf Of
Paul Rolland
> > > Sent: Tuesday, August 15, 2006 11:11 AM
> > > To: openh323openh323.org
> > > Cc: rolas2917.net
> > > Subject: RE: [OpenH323]Opal - Some
questions...
> > >
> > > Hello,
> > >
> > > Regarding the first problem, I've added
traces to the code,
> > > and here is what
> > > I can see for the two transcoders created on
the caller side :
> > >
> > > First transcoder :
> > >
> > > 9 [9:06] rolref-dev:~...opal/samples/simple> grep 80abcf0
> > > caller.txt | grep
> > > -v g711codec | grep -v " 0 sampl"
> > > 0:07.655 Media Patc...ch:80abcf0
patch.cxx(217)
> > > Patch Thread
> > > started for Patch
OpalAudioMediaStream-Source-PCM-16 ->
> > > OpalRTPMediaStream-Sink-G.711-uLaw-64k
> > > 0:07.665 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:08.277 Media Patc...ch:80abcf0
rtp.cxx(992)
> > > RTP First
> > > sent data: ver=2 pt=PCMU psz=160 m=1 x=0
seq=41440 ts=0
> > > src=59615544 ccnt=0
> > > 0:08.304 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:10.537 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:10.941 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:11.854 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:13.282 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > > 0:14.275 Media Patc...ch:80abcf0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 160, using 16 bits
as input and 8
> > as output
> > >
> > > Second transcoder :
> > >
> > > 10 [9:07] rolref-dev:~...opal/samples/simple> grep 80ad6d0
> > > caller.txt | grep
> > > -v g711codec | grep -v " 0 sampl"
> > > 0:07.781 Media Patc...ch:80ad6d0
patch.cxx(217)
> > > Patch Thread
> > > started for Patch
OpalRTPMediaStream-Source-G.711-uLaw-64k ->
> > > OpalAudioMediaStream-Sink-PCM-16
> > > 0:07.786 Media Patc...ch:80ad6d0
jitter.cxx(303)
> > > RTP Jitter
> > > buffer created: size=51 delay=400-2000/400
(50ms) obj=0x80afb78
> > > 0:07.901 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:09.119 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:10.261 Media Patc...ch:80ad6d0
jitter.cxx(676)
> > > RTP Jitter
> > > buffer target realigned to current jitter
buffer
> > > 0:10.264 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:11.203 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:12.220 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:13.160 Media Patc...ch:80ad6d0
jitter.cxx(676)
> > > RTP Jitter
> > > buffer target realigned to current jitter
buffer
> > > 0:13.163 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:14.182 Media Patc...ch:80ad6d0
jitter.cxx(676)
> > > RTP Jitter
> > > buffer target realigned to current jitter
buffer
> > > 0:14.183 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:15.123 Media Patc...ch:80ad6d0
jitter.cxx(676)
> > > RTP Jitter
> > > buffer target realigned to current jitter
buffer
> > > 0:15.126 Media Patc...ch:80ad6d0
> > transcoders.cxx(454) Trans
> > > Converting 160 samples to 320, using 8 bits
as input and 16
> > as output
> > > 0:15.179 Media Patc...ch:80ad6d0
g711cod
> > >
> > > I really don't understand. One should be
transcoding from
> > > PCM-16 to G711, and
> > > the other one from G711 to PCM16.
> > >
> > > So, why is one converting from 160 to 320
samples while the
> > other one
> > > is doing 160 to 160 ???
> > >
> > > Please help, I'm really lost in the data
path/data flow, and
> > > I can't find
> > > what's wrong ...
> > >
> > > Paul Rolland, rol(at)as2917.net
> > > ex-AS2917 Network administrator and Peering
Coordinator
> > >
> > > --
> > >
> > > Please no HTML, I'm not a browser - Pas
d'HTML, je ne suis
> > > pas un navigateur
> > > "Some people dream of success... while
others wake up and
> > > work hard at it"
> > >
> > > "I worry about my child and the
Internet all the time, even
> > > though she's too
> > > young to have logged on yet. Here's what I
worry about. I
> > > worry that 10 or 15
> > > years from now, she will come to me and say
'Daddy, where
> > > were you when they
> > > took freedom of the press away from the
Internet?'"
> > > --Mike Godwin, Electronic Frontier Foundation
> > >
> > >
> > > > -----Original Message-----
> > > > From: openh323-adminopenh323.org
> > > > [mailto:openh323-adminopenh323.org] On Behalf Of Paul Rolland
> > > > Sent: Friday, August 11, 2006 6:51 PM
> > > > To: openh323openh323.org
> > > > Cc: rolas2917.net
> > > > Subject: [OpenH323]Opal - Some
questions...
> > > >
> > > > Hello,
> > > >
> > > > I've a bunch of questions regarding
Opal... Some are
> > > probably stupid,
> > > > but I'd like to have the opinion of
people who have been
> > > > using it for long...
> > > >
> > > > First question :
> > > > 1 - I've written a pwlib plugin,
sound_wav, that I'm using as
> > > > a replacement
> > > > for sound_oss (or sound_alsa), and
it is basically
> > > > reading from/writing
> > > > to WAV files.
> > > >
> > > > 2 - I'm using it with a GW using the
G.711 codec, but the
> > > sound I have
> > > > on the phone line out of the gateway
is bad (though it is
> > > > possible to
> > > > make sure the sound is the one of
the source WAV file).
> > > > I suspect this is coming from the
expectation of what
> > > > should be delivered
> > > > by a PSoundChannel::Read, but I
can't find where to
> > > look, as the
> > > > PSoundChannel::Open is saying :
> > > > 0:04.903 SIP Handle...er:80789f0
sound_wav.cxx(264)
> > > > WAV::Open of in1.wav for 1 channels,
8000Hz, 16 bits per sample
> > > >
> > > > and the file in1.wav is conforming to
these specifications :
> > > > 56 [15:28] rolref-dev:~...opal/samples/simple> file in1.wav
> > > > in1.wav: RIFF (little-endian) data, WAVE
audio, Microsoft
> > > > PCM, 16 bit, mono
> > > > 8000 Hz
> > > >
> > > > So, there shouldn't be any resampling
need, which is why I'm
> > > > running with
> > > > resampleRate set to 0.
> > > >
> > > > What's more, I have the following :
> > > > 0:16.093 SIP Handle...er:80c4c98
patch.cxx(323)
> > > > Patch Added
> > > > sink
> > > > from PCM-16
> > > > Clock Rate = 8000
> > > > Frame Time = 8
> > > > Max Bit Rate = 64000
> > > > Max Frame Size = 16
> > > > Needs Jitter = 1
> > > > Rx Frames Per Packet = 240
> > > > Tx Frames Per Packet = 30
> > > > to G.711-uLaw-64k
> > > > Clock Rate = 8000
> > > > Frame Time = 8
> > > > Max Bit Rate = 64000
> > > > Max Frame Size = 8
> > > > Needs Jitter = 1
> > > > Rx Frames Per Packet = 240
> > > > Tx Frames Per Packet = 30
> > > >
> > > > and
> > > > 0:16.149 SIP Handle...er:80c4c98
patch.cxx(323)
> > > > Patch Added
> > > > sink
> > > > from G.711-uLaw-64k
> > > > Clock Rate = 8000
> > > > Frame Time = 8
> > > > Max Bit Rate = 64000
> > > > Max Frame Size = 8
> > > > Needs Jitter = 1
> > > > Rx Frames Per Packet = 240
> > > > Tx Frames Per Packet = 30
> > > > to PCM-16
> > > > Clock Rate = 8000
> > > > Frame Time = 8
> > > > Max Bit Rate = 128000
> > > > Max Frame Size = 16
> > > > Needs Jitter = 1
> > > > Rx Frames Per Packet = 240
> > > > Tx Frames Per Packet = 30
> > > >
> > > > That seems to says the two (PCM-16 and
G.711) are the same
> > > > except for the
> > > > max frame size.
> > > >
> > > > On the other hand, Opal does contain an
OpalWavFile class,
> > > > that is said
> > > > to "tranparently convert all data
to/from PCM format". But
> > > > could this help ?
> > > > I was expecting the conversion to be
done at the
> > MediaPatch level...
> > > > I'm sure missing something important,
but can't find out :(
> > > >
> > > > This is even more puzzling that pcss.cxx
contains the
> > > following code :
> > > > OpalMediaFormatList
OpalPCSSEndPoint::GetMediaFormats() const
> > > > {
> > > > OpalMediaFormatList formats;
> > > >
> > > > formats += OpalPCM16; // Sound card
can only do 16 bit PCM
> > > >
> > > > so the format really seems to be the
good one !
> > > >
> > > >
> > > >
> > > > Second question : when the WAV file is
finished reading (or
> > > > at any time while
> > > > it is being read), I'd like to switch
to a new source. I've
> > > > been looking at
> > > > the OpalMediaPatch which includes
functions to Add and Remove
> > > > a Sink, so I
> > > > guess
> > > > I can change the Sink while the
connection is established,
> > > but nothing
> > > > regarding
> > > > the Source. Is there any reason not to
duplicate AddSink and
> > > > RemoveSink to
> > > > have AddSource and RemoveSource ? And if
only one Source is
> > > > allowed, why
> > > > not having an atomic (from the ::Main
point of view...)
> > > ChangeSource ?
> > > > This is important, because as soon as
the WAF file is
> > > > finished reading,
> > > > the process is entering a kind of busy
loop reading the file,
> > > > thus getting
> > > > all the CPU the machine has... so I'd
like to switch to
> > > > reading /dev/null 
> > > >
> > > >
> > > > Well, finally, only two questions... Not
that much ;)
> > > >
> > > > Regards,
> > > > Paul
> > > >
> > > >
------------------------------------------------------------
--
> > > > ----------
> > > > Check the FAQ before asking! -
> > > > http://www.
openh323.org/~openh323/fom.cgi
> > > > The OpenH323 Project mailing list, using
Mailman. To
> > unsubscribe or
> > > > change your subscription options, goto
> > > > htt
p://www.openh323.org/mailman/listinfo/openh323
> > > > Maintained by Quicknet Technologies, Inc
- http://www.quicknet.net
> > > >
------------------------------------------------------------
--
> > > > ----------
> > > >
> > >
> > >
------------------------------------------------------------
--
> > > ----------
> > > Check the FAQ before asking! -
> > > http://www.
openh323.org/~openh323/fom.cgi
> > > The OpenH323 Project mailing list, using
Mailman. To unsubscribe or
> > > change your subscription options, goto
> > > htt
p://www.openh323.org/mailman/listinfo/openh323
> > > Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
> > >
------------------------------------------------------------
--
> > > ----------
> > >
> >
>
>
------------------------------------------------------------
------------
> Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
> The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
> change your subscription options, goto
> htt
p://www.openh323.org/mailman/listinfo/openh323
> Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>
------------------------------------------------------------
------------
>
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derekindranet.co.nz
ph +64 3 365 6485
Web: http://www.indr
anet-technologies.com/
------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------
|
Hello,
> timing is provided by the write and read source.
>
> For a 480 bytes of pcm data, the speaker system is
guaranteed
> to take 30ms
> to play it - which is your timing.
>
> Similarily, to read 480 bytes, that takes 30ms.
((Assuming
> 8khz audio))
So, if I am correct, when the Patch thread goes to read data
from the source,
wanting 320 bytes, the operation is expected to be at most
20ms, and in fact
will be a 20ms operations if two consecutive Read are
performed, as this
is the delay that is required by the PCM source to provide
that amount of
data.
Thus, as my WAV file is simulating a PCM input device, I
have to estimate
how long ago was the previous read of 320bytes, how long
does a read of that
number of bytes should last (20ms), and then ensure that the
Read will not
return before 20ms, counted from the end of the previous
Read operation,
to ensure that each Read of 320 bytes end no faster than one
every 20ms.
Is this correct for this first part ?
But, in fact, it is more complicated, as this is not
expected to be a set
of independant operations... So, all this has to be
considered as a global
buffer from the Setup time, so the n'th Read should return
at most n * 20ms
after the Setup was finished...
Is this correct ?
This means that I need to :
- store the time the setup was finished (this is the time
the PCM device
starts
having data in its internal buffer),
- store the number of Read done since Setup (or the number
of bytes),
- estimate how long I have to delay the end of each Reach
based on these two
values.
Is that better ?
Regards,
Paul
------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------
|