24 Jul
2011
24 Jul
'11
2:02 p.m.
Hi all
Re: Pepijn message.
I too was wondering how the u-plane data was passed to the codec.
300-395-2 states that acelp-codec requires 2 * (137+1) 16bit samples per frame
and not 216 + 216 bits indicated in the tch reordering file comments.
Any assistance would be greatly appreciated.
Best regards.
Graham.
25 Jul
25 Jul
9:39 a.m.
On Sun, Jul 24, 2011 at 01:02:40PM +0100, Graham Palmer wrote:
I too was wondering how the u-plane data was passed to
the codec.
300-395-2 states that acelp-codec requires 2 * (137+1) 16bit samples per frame
and not 216 + 216 bits indicated in the tch reordering file comments.
This is the input to the codec, i.e the PCM audio data.
the 216 + 216 bits are the encoded data, i.e. the codec output (which is
the decoder input).
The re-ordering code in osmo-tetra is untested. You can feed the raw
burst bits into the ETSI reference codec, as it includes the error
correction / viterbi decoder.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
26 Jul
26 Jul
8:26 p.m.
Thank you Harald for the response.
It seems to be working now although the only sounds we hear are "digital
sounding" clicks and pops.
Thanks again.
- Pepijn
Op 25 jul 2011, om 09:39 heeft Harald Welte het volgende geschreven:
On Sun, Jul 24, 2011 at 01:02:40PM +0100, Graham
Palmer wrote:
I too was wondering how the u-plane data was
passed to the codec.
300-395-2 states that acelp-codec requires 2 * (137+1) 16bit samples per frame
and not 216 + 216 bits indicated in the tch reordering file comments.
This is the input to the codec, i.e the PCM audio data.
the 216 + 216 bits are the encoded data, i.e. the codec output (which is
the decoder input).
The re-ordering code in osmo-tetra is untested. You can feed the raw
burst bits into the ETSI reference codec, as it includes the error
correction / viterbi decoder.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:08 p.m.
Thank you Harald for the response.
It seems to be working now although the only sounds we hear are "digital
sounding" clicks and pops.
Thanks again.
- Pepijn
Op 25 jul 2011, om 09:39 heeft Harald Welte het volgende geschreven:
On Sun, Jul 24, 2011 at 01:02:40PM +0100, Graham
Palmer wrote:
I too was wondering how the u-plane data was
passed to the codec.
300-395-2 states that acelp-codec requires 2 * (137+1) 16bit samples per frame
and not 216 + 216 bits indicated in the tch reordering file comments.
This is the input to the codec, i.e the PCM audio data.
the 216 + 216 bits are the encoded data, i.e. the codec output (which is
the decoder input).
The re-ordering code in osmo-tetra is untested. You can feed the raw
burst bits into the ETSI reference codec, as it includes the error
correction / viterbi decoder.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4658
days inactive
4660
days old
3 comments
4 participants
participants (4)
-
Graham Palmer -
Harald Welte -
Pepijn van den Berkhof -
Pepijn van den Berkhof