DTS Support, Audio track selection, USB full screen mode

[doodlecz]

Thanks for the tip, injection works beautifully now.

I was able to dump bytes 00 00 01 BD 08 CD 85 C0 0A 31 00 03 D0 11 11 00 01 00 01 which is PES header of AC3 frame created by exeDSP.
In theory, I think it could be possible to read DTS frame from the source audio and encapsulate it in similar way as AC3 packet is made.
Does anyone have practical experience with these things? (After some googling, I'm also master of theory )

[erdem_ua]

It looks like DTS support incoming.
So I have just enabled donations to project from now.

[doodlecz]

Just short info about (almost no) progress.
DTS audio stream read from MKV is imo correct when DTS stream is processed as AC3 (packets with DTS sync word on the beginning and correct length are read)
The problem seems to be only in PES header, which is created by exeDSP and is not created correctly for DTS stream - it seems the problem is related to the PTS field in PES header. I have to learn more about this..
If someone would like to participate, I could attach my sources logging PES headers, packets etc.

[sbav1]

Just short info about (almost no) progress.
DTS audio stream read from MKV is imo correct when DTS stream is processed as AC3 (packets with DTS sync word on the beginning and correct length are read)
The problem seems to be only in PES header, which is created by exeDSP and is not created correctly for DTS stream - it seems the problem is related to the PTS field in PES header. I have to learn more about this..

Hmm, I'm not sure I fully understand all this.. It looks like TV is encapsulating AC3 packets with PES headers for future processing (in uldAvfd_InterfacerAudioAc3TransferBufDataWithPESHdr ?) but I can't find where are those headers striped before sending packets to SPDIF. Is it done by some function[s] in samdrv.ko module, or maybe directly in hardware audio engine?
There are many low-level functions for SPDIF Tx setup in samdrv.ko, and some related options in debug menu, but for me they are not very entlighting. I guess it is still not sure if samsung SPDIF is able to transmit DTS stream hardware-wise, am I right?
I looked into samdrv.ko (the better part of it is apparently related to audio decoding, mostly "AIDA" engine microcodes for various audio formats), and - oh boy- samsung sound processing is just FUBAR
Does anyone know an easy method for adjusting kernel-level dubugging loglevels temporarilly by some exeDSP function call? It is possible to switch debugging on/off for various subsystems in debug menu, but those settings are remebred in NVRAM between reboots, which may be a little dangerous sometimes (as I learned in hard way).

[sbav1]

If someone would like to participate, I could attach my sources logging PES headers, packets etc.

Do you think, may it be possible to capture / dump audio streams from (e.g) uldAvfd_InterfacerSkipUnknownData()
or uldAvfd_InterfacerSkipUnknownEsData() ? I want to try some things.

Recently I got my hands on external USB sound card (Creative Sound Blaster Live! 24-bit External USB). As it turned out, after some fiddling, it also works while connected to the TV . Compiling kernel modules for USB audio is the easy part; setting up & configuring ALSA not that easy one.. But basically it works, except for the mixer (very limited settings available for analog audio; it's a known limitation for this device on older kernels and alsa versions).
Stereo and 5.1 pcm/wav files are playable with aplay (from debian lenny armel alsa-utils package), and SPDIF passthrough for AC3 & DTS files seems to work well with mplayer.

To test software DTS decoding possibilities I [cross]compiled libdca/dcadec, ffmpeg and mplayer for ARM v6 CPU with VFP optimizations turned on, and here are preliminary results:
- ffmpeg DTS decoding implementation seems to be the most efficient (ca. 30% CPU utilisation while decoding and playing .dts files in real time, with stereo downmixing); some patching may be required, as recent ffmpeg from current CVS snapshot is unable to downmix 5.1 DTS audio to stereo on arm v6 platform;
- for some reasons DTS software decoding is not working with my test mplayer binary; on the other hand, this mplayer is able to do DTS/AC3 passthrough from TV to external USB sound card with just 3-5% CPU;
- dcadec can decode and play *.dts files directly to external sound card (through oss compatibily layer, in. 2.0 and 5.1 modes), but is significantly slower (45-65% CPU) compared to ffmpeg. It's visibly faster with dts decoding to .wav file; I don't know, maybe oss -> alsa pathway is responsible for some additional overhead (?).

Surely external USB sound card is not in any way practical remedy for samsung "DTS audio handling problem", but I think test results imply that some properly implemented DTS software decoding on TV embeeded ARM may be quite doable..
I'm pretty sure samsung chelsea chip should not overheat/desolder itself from mainboard with just 30% extra cycles on ARM core .

[doodlecz]

Yes, it is possible to dump those streams. In fact, I'm dumping PES header and data from audio stream within the function you mention.
Also I've redirected DTS stream to this function but with no effect - btw, DTS packets seem to be read correctly (correct size) from the stream by these functions.
I think those functions related with ES will not be usable for DTS, because the AC3 stream is encapsulated and sent as MPEG2 stream to the decoder - in the same way as i.e. DVT-B stream. I tried to create correct (?) PES header containing DTS data and it didn't work - I suppose, it is not generally supported by my decoder. Also I tried to send only DTS data instead of PES packet (padded to the correct length as used in padded DTS) with no effect.
I have X-Fi with optical in so I want to try to record input from TV, just for check. I hope tomorrow I'll move my computer to get it near the TV
I also think, it might be possible to make downmix or reencoding to AC3 but still no test done.
Regarding the SPDIF, I want to check / dump data from spIAio_StartSpdifOut, it seems to be interesting but also I didn't found SPDIF header contants.. need to check samdrv.ko.
Log enabling by function call is possible (or better - adjust exported log variables to your needs..), but I found it generates so much information during movie play, it causes problems..

[sbav1]

Yes, it is possible to dump those streams. In fact, I'm dumping PES header and data from audio stream within the function you mention.

Maybe you can share some code for audio stream / audio buffer capture (preferably from uldAvfd_InterfacerSkipUnknownEsData() - if it is even possible from inside this function ?). I will be very gratefull.

I have X-Fi with optical in so I want to try to record input from TV, just for check. I hope tomorrow I'll move my computer to get it near the TV

I tried similar thing (ie. using PC with spdif input as a receiver for PCM/AC3/DTS audio) ~2 years ago and I remeber it was very painfull and basicaly fruitless experience. But according to http://www.avsforum.com/avs-vb/showthread.php?t=1121367 thread it may actually work on some X-Fi versions, if you get really lucky

I also think, it might be possible to make downmix or reencoding to AC3 but still no test done.

Hmm, DTS decoding & downmixing to stereo PCM seems to be doable (30% CPU).
Transcoding 5.1 dts audio to 5.1 AC3 on TV in realtime is probably not very realistic (certainly not unless some heavy decoder / encoder optimizations can be developed for ARM v6). In my tests I got (at best) 16-18 fps transcoding speed for 24fps mkv movies. And it looks like exeDSP needs ~25% CPU just for itself while playing 720p mkv file..
If someone wants to try software decoding methods I may be of some help; I gained a little experience in configuring and crosscompiling ffmpeg/mplayer for ARM architecture and I have some patches (required for ffmpeg downmixing) allready prepared.

[doodlecz]

I'll check this function, but I think it does not make sense to use these skipper functions - we will have to redirect DTS stream from uknown to something known (PCM (?) if we will try to downmix or do anything else) probably anyway because there is a lot of other processing made for "known" streams..

Would it be possible to prepare kind of library with downmixing function usable on TV? I mean function which takes buffer with DTS packet (starting by DTS sync) as input and fills some output buffer with downmixed PCM buffer?

[sbav1]

I'll check this function, but I think it does not make sense to use these skipper functions - we will have to redirect DTS stream from uknown to something known (PCM (?) if we will try to downmix or do anything else) probably anyway because there is a lot of other processing made for "known" streams..

Undoubtedly, you're right about the skipping function.. I just wanted to check if the "unknown" audio stream might be (more or less) directly redirectable to (e.g.) USB sound card SPDIF out. But I'm well aware it's not exactly very important for all practical purposes

Would it be possible to prepare kind of library with downmixing function usable on TV? I mean function which takes buffer with DTS packet (starting by DTS sync) as input and fills some output buffer with downmixed PCM buffer?

Sure it's possible. I'll look into it in detail ( may take a couple of days, as my C programming "skills" are - let's say - a little rusty).

BTW, I only just found this not-so-widely-known http://forum.samygo.tv/viewtopic.php?f= ... 4803#p4803 nice little debug/logging app of yours. I presume, individual log levels can be enabled/disabled/adjusted for particular subsystems only, with a little additional insight..
Oh, it certainly looks like fun

[doodlecz]

Sure it's possible. I'll look into it in detail ( may take a couple of days, as my C programming "skills" are - let's say - a little rusty).

That would be great.
Btw, I was able to record _something_ from TV via X-fi Elite Pro SPDIF-In. Also I tried using AC3Filter to decode the stream recieved from TV but with no success. Stereo is fine, but AC3 seems to be sent as compressed 2 channel PCM (at least AC3Filter shows 2 channels with "sound"), but AC3Filter cannot decompress it. Looking into captured data, it seems, packets are about 600B long. However, I'm not sure, if captured data are OK. I could post it here, if you're interested.
Using built-in Dolby Digital/DTS decoder for SPDIF-In was working (i think). So it didn't help much.

Regarding the debugging application, you're right. Just check what text you'd like to log and adjust variables. Btw, if I remember correctly, later I found a minor bug - the value g_u32PrintModule is in fact 64b (there's is more than 32 modules), so also following 4 bytes should be also set to 0xFFFFFFFF if you'd like to log really everything..

I hope during this weekend I'll be able to make some tests.