FIXME: the format description gathered here does not seem to be the same
in comparison to the format description collected from the actual sampleBuffer.
This information needs to be updated some other place. For the time being this shall suffice.
The following verbose output is an example of what is read from the input device during the below block
[0x3042138] qtsound demux debug: Audio localized format summary: Linear PCM, 24 bit little-endian signed integer, 2 channels, 44100 Hz
[0x3042138] qtsound demux debug: Sample Rate: 44100; Format ID: lpcm; Format Flags: 00000004; Bytes per Packet: 8; Frames per Packet: 1; Bytes per Frame: 8; Channels per Frame: 2; Bits per Channel: 24
[0x3042138] qtsound demux debug: Flag float 0 bigEndian 0 signedInt 1 packed 0 alignedHigh 0 non interleaved 0 non mixable 0
canonical 0 nativeFloatPacked 0 nativeEndian 0
However when reading this information from the sampleBuffer during the delegate call from
2011-09-23 22:06:03.077 VLC[23070:f103] Audio localized format summary: Linear PCM, 32 bit little-endian floating point, 2 channels, 44100 Hz
2011-09-23 22:06:03.078 VLC[23070:f103] Sample Rate: 44100; Format ID: lpcm; Format Flags: 00000029; Bytes per Packet: 4; Frames per Packet: 1; Bytes per Frame: 4; Channels per Frame: 2; Bits per Channel: 32
2011-09-23 22:06:03.078 VLC[23070:f103] Flag float 1 bigEndian 0 signedInt 0 packed 1 alignedHigh 0 non interleaved 1 non mixable 0
canonical 1 nativeFloatPacked 1 nativeEndian 0
Note the differences
24bit vs. 32bit
little-endian signed integer vs. little-endian floating point
format flag 00000004 vs. 00000029
bytes per packet 8 vs. 4
packed 0 vs. 1
non interleaved 0 vs. 1 -> this makes a major difference when filling our own buffer
canonical 0 vs. 1
nativeFloatPacked 0 vs. 1
One would assume we'd need to feed the (es_format_t)audiofmt with the data collected here.
This is not the case. Audio will be transmitted in artefacts, due to wrong information.
At the moment this data is set manually, however one should consider trying to set this data dynamically
msg_Dbg(p_demux, "Sample Rate: %.0lf; Format ID: %s; Format Flags: %.8x; Bytes per Packet: %d; Frames per Packet: %d; Bytes per Frame: %d; Channels per Frame: %d; Bits per Channel: %d",
msg_Err(p_demux,"audio output could not be added to capture session (%ld)",[o_returnedAudioErrorcode]);
gotoerror;
}
/* Get the formats */
/*
FIXME: the format description gathered here does not seem to be the same
in comparison to the format description collected from the actual sampleBuffer.
This information needs to be updated some other place. For the time being this shall suffice.
The following verbose output is an example of what is read from the input device during the below block
[0x3042138] qtsound demux debug: Audio localized format summary: Linear PCM, 24 bit little-endian signed integer, 2 channels, 44100 Hz
[0x3042138] qtsound demux debug: Sample Rate: 44100; Format ID: lpcm; Format Flags: 00000004; Bytes per Packet: 8; Frames per Packet: 1; Bytes per Frame: 8; Channels per Frame: 2; Bits per Channel: 24
[0x3042138] qtsound demux debug: Flag float 0 bigEndian 0 signedInt 1 packed 0 alignedHigh 0 non interleaved 0 non mixable 0
canonical 0 nativeFloatPacked 0 nativeEndian 0
However when reading this information from the sampleBuffer during the delegate call from
2011-09-23 22:06:03.077 VLC[23070:f103] Audio localized format summary: Linear PCM, 32 bit little-endian floating point, 2 channels, 44100 Hz
2011-09-23 22:06:03.078 VLC[23070:f103] Sample Rate: 44100; Format ID: lpcm; Format Flags: 00000029; Bytes per Packet: 4; Frames per Packet: 1; Bytes per Frame: 4; Channels per Frame: 2; Bits per Channel: 32
2011-09-23 22:06:03.078 VLC[23070:f103] Flag float 1 bigEndian 0 signedInt 0 packed 1 alignedHigh 0 non interleaved 1 non mixable 0
canonical 1 nativeFloatPacked 1 nativeEndian 0
Note the differences
24bit vs. 32bit
little-endian signed integer vs. little-endian floating point
format flag 00000004 vs. 00000029
bytes per packet 8 vs. 4
packed 0 vs. 1
non interleaved 0 vs. 1 -> this makes a major difference when filling our own buffer
canonical 0 vs. 1
nativeFloatPacked 0 vs. 1
One would assume we'd need to feed the (es_format_t)audiofmt with the data collected here.
This is not the case. Audio will be transmitted in artefacts, due to wrong information.
At the moment this data is set manually, however one should consider trying to set this data dynamically
msg_Dbg(p_demux, "Sample Rate: %.0lf; Format ID: %s; Format Flags: %.8x; Bytes per Packet: %d; Frames per Packet: %d; Bytes per Frame: %d; Channels per Frame: %d; Bits per Channel: %d",