Re: [RFT] Major snd_hda rewrite

2012/1/24 Alexander Motin <mav_at_freebsd.org>

> On 01/24/12 15:32, Alexander Motin wrote:
>
>> On 01/24/12 14:57, Mickaël Maillot wrote:
>>
>>> 2012/1/21 Alexander Motin <mav_at_freebsd.org <mailto:mav_at_freebsd.org>>
>>> From that description I can conclude that you are passing through
>>> compressed DTS-HD and TrueHD streams to the receiver. What are the
>>> bitrates of streams you are playing? It looks like your receiver
>>> doesn't receives all data. If I understand right, to transfer with
>>> compressed bitrates above 6.144Mbps special High Bit Rate mode
>>> should be activated in CODEC, when data stream occupies all 8 HDMI
>>> channels instead of 2. I haven't implemented this feature yet as my
>>> receiver doesn't support such HD formats.
>>>
>>>
>>> i dont think bitrate is over 6.144Mbps.
>>> for TrueHD files, mediainfo reports:
>>>
>>> Format profile : TrueHD / Core
>>> Mode extension : CM (complete main)
>>> Codec ID : 131
>>> Bit rate mode : Variable / Constant
>>> Bit rate : Unknown / 640 Kbps
>>> Maximum bit rate : 2 868 Kbps / 640 Kbps
>>> Channel(s) : 6 channels
>>>
>>> and for DTS-HDMA, mediainfo can't calculate it, but from description,
>>> all tested file have bitrate below 3689 kbps
>>>
>>
>> Then make sure that your player properly sets "sampling rate" for the
>> playback. Data transferred as "16bit stereo", but depending on bit rate
>> may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps
>> and 6Mbps respectively). For higher bit rates stream transferred as
>> 8-channel (High Bit Rate mode) with same set of frequencies (but now up
>> to 12, 24 and 49Mbps).
>>
>>  I'll try to make a patch for it a bit later and send you to try.
>>>
>>> i'll be happy to try it.
>>>
>>
> Here is it: http://people.freebsd.org/~**mav/hda.HBR.patch<http://people.freebsd.org/~mav/hda.HBR.patch>
> It should activate HBR mode if you try to play stream with AC3 format and
> 8 channels (>6Mbps).
>
>
no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3,
SNDCTL_DSP_CHANNELS always return 2 channels even if i set SNDCTL_DSP_SPEED
to 192000.
and i think it's why "if ((ch->fmt & AFMT_AC3) && (cchn == 8))" can't be
true.
i checked my /v/l/messages and saw PCMDIR_PLAY ....chan_count=0x01.

i can set 8 channels without problems with AFMT_S32_LE format and sound
works:
kernel: hdac1: 36864Kbps of 92160Kbps bandwidth used
kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02801000 (7.1) speed=192000
kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1837, dfmt=0x0001,
chan=0x0010, chan_count=0x07, stripe=1

>
>  Until that time, is it possible to make your xbmc to decode those HD
>>> streams into different number of uncompressed LPCM channels to play
>>> it that way?
>>>
>>>
>>> yes, it's just an option.
>>>
>>> It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM
>>> configurations with your receiver. Or at least normal definition 7.1
>>> playback would be interesting to test (you can just set vchanformat
>>> to s16le:7.1 or s32le:7.1 and play anything).
>>>
>>> i sucessfully tried 6.1 and 7.1 LPCM in 16 bits.
>>> just a small channel order issue (center and a surround back inversion)
>>> which can be solved easily.
>>>
>>
>> In what number of channels which channels are swapped specifically? I've
>> compared mapping I am setting in driver with data I have and found no
>> problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left,
>> Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've
>> never could check what mplayer thinks about it because I have no such
>> such media. Can you give me some example?
>>
>>
ok mapping is good, i think the swap is in XBMC, i'll check later with
xbmc's audio dev.


>  i'll add 32bits support in XBMC later for my test but from what you say,
>>> it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s.
>>>
>>
>> 6Mbps limitation is only for data, as they use only two channels by
>> default. Audio stream has no such limit.
>>
>
>
yep, it works !