Obsolete
Status Update
Comments
mi...@gmail.com <mi...@gmail.com> #2
I would love to have this feature enabled. (No PCM conversion, no DSD over PCM [DoP] encapsulation - just plain native DSD according to the HDMI specs.)
jo...@gmail.com <jo...@gmail.com> #3
I would love and buy this!
ph...@google.com <ph...@google.com> #4
This is the public version of b/73863134
We want to keep this open so folks can leave comments.
So instead of DUPing it, let's make b/73863134 a blocking bug.
We want to keep this open so folks can leave comments.
So instead of DUPing it, let's make
wa...@gmail.com <wa...@gmail.com> #5
This would be a very welcome feature. Please make it happen.
ed...@gmail.com <ed...@gmail.com> #6
And also multichannel DSD must be added
th...@googlemail.com <th...@googlemail.com> #7
This request is not directly related to the Super AudioCD [DSD64], but in case anyone is wondering about legal issues:
http://www.ip.philips.com/licensing/program/45
1. all patents concerning the AUDIO format on SACDs have already expired by 2017
2. the few remaining patents (expiring 2018 and 2019), only deal with file structures on SACD [e.g. TOC]
3. Philips and Sony lost interest in DSD many years ago, hence DSD downloads could flourish
Interestingly the Dutch
http://www.ip.philips.com/data/downloadables/1/5/7/6/exha-sacddisc-philips-joint-2009-march-20.pdf?force-download=yes
were more diligent in filing patents
than their Japanese partners ;-)
http://www.ip.philips.com/data/downloadables/1/5/7/7/exha-sacddisc-sony-joint-07-2002.pdf?force-download=yes
1. all patents concerning the AUDIO format on SACDs have already expired by 2017
2. the few remaining patents (expiring 2018 and 2019), only deal with file structures on SACD [e.g. TOC]
3. Philips and Sony lost interest in DSD many years ago, hence DSD downloads could flourish
Interestingly the Dutch
were more diligent in filing patents
than their Japanese partners ;-)
kr...@googlemail.com <kr...@googlemail.com> #8
Really interested in this.
I currently have a Linux box which doesn't have the CPU grunt needed to decode DSD 5.1 to PCM so that would really benefit from this (If needed driver support is there) but support just in Android is still a good step forward.
I currently have a Linux box which doesn't have the CPU grunt needed to decode DSD 5.1 to PCM so that would really benefit from this (If needed driver support is there) but support just in Android is still a good step forward.
ed...@gmail.com <ed...@gmail.com> #9
I don't understand why it is not there by default, it is in the Hdmi standard, please add it to Android 8 Oreo, both stereo and multichannel DSD.
And to Nvidia Shield TV 2015 and 2017.
And to Nvidia Shield TV 2015 and 2017.
ja...@gmail.com <ja...@gmail.com> #10
After much time and expense I have finally accepted that this functionality is just not possible in Windows - I should have done more research - so I would very much like to support the request for it to be implemented in Android.
[Deleted User] <[Deleted User]> #11
Yes, please!
po...@gmail.com <po...@gmail.com> #12
That 'd be great
mc...@gmail.com <mc...@gmail.com> #13
I would also love this feature and be willing to buy the option for my Shield TV
ev...@gmail.com <ev...@gmail.com> #14
Yes, please
th...@googlemail.com <th...@googlemail.com> #15
Nice to see that interest and support is still pouring in. Please also consider hitting the STAR SYMBOL ["Indicate that you are affected by this issue"] on the top left corner.
dw...@gmail.com <dw...@gmail.com> #16
Yes. We just need Android to have the ability to at least pass it through to a decoder like a stereo receiver.
mi...@gmail.com <mi...@gmail.com> #17
I too can use this feature and welcome it heartily!
ph...@gmail.com <ph...@gmail.com> #18
i would love to be able to play SACD ISOs (DSD over HDMI)
ph...@google.com <ph...@google.com>
vi...@gmail.com <vi...@gmail.com> #19
I have a large library of DSD files and it would be great if I could play it on my Shield TV
do...@donlindbergh.com <do...@donlindbergh.com> #20
Another user very interested in this.
ar...@gmail.com <ar...@gmail.com> #21
Another user would love to play DSD files.
an...@gmail.com <an...@gmail.com> #22
Please add this feature to Android
so...@gmail.com <so...@gmail.com> #23
I would also like this feature to be added in Android, especially Nvidia Shield. Bear in mind that for those owning a Denon or Marantz receiver, it can be done through Heos app.
kw...@gmail.com <kw...@gmail.com> #24
I would also like this feature to be added in Android, especially Nvidia Shield.
th...@gmail.com <th...@gmail.com> #25
A must for audiophiles! Would love to see this feature soon on android!
ma...@gmail.com <ma...@gmail.com> #26
+1
re...@gmail.com <re...@gmail.com> #27
+1
me...@gmail.com <me...@gmail.com> #28
Any chance for this to get implemented?
vi...@gmail.com <vi...@gmail.com> #29
+1
sa...@gmail.com <sa...@gmail.com> #30
+1
te...@gmail.com <te...@gmail.com> #31
+1
al...@gmail.com <al...@gmail.com> #32
Please add this feature
te...@gmail.com <te...@gmail.com> #33
Please add this feature
ha...@lottobaes.com <ha...@lottobaes.com> #34
+1
ve...@gmail.com <ve...@gmail.com> #35
+1
21...@gmail.com <21...@gmail.com> #36
have any progress at this problem?
po...@gmail.com <po...@gmail.com> #37
Hi all, I m curious about progress in this feature too.
we...@gmail.com <we...@gmail.com> #38
very love to have the feature
mi...@gmail.com <mi...@gmail.com> #39
That would be quite useful!
ic...@gmail.com <ic...@gmail.com> #40
Agree.
je...@gmail.com <je...@gmail.com> #41
+1 there is no solution at all now.
ma...@gmail.com <ma...@gmail.com> #42
+1 Please add
go...@gmail.com <go...@gmail.com> #43
there's a solution which is to avoid using libaudio and use the embedded usb audio driver of apps such as "USB audio player pro" which is capable of bitperfect streaming over usb to a connected dac...this is far from perfect and seems more like a hack as to avoid the grotesque resampling done by Android's core audio driver
br...@gmail.com <br...@gmail.com> #44
Please add this feature, it will make a lot of audiophiles happy!!!
bo...@gmail.com <bo...@gmail.com> #45
please support this request. Most new AVRs support native DSD over HDMI avoiding any transcode. DLNA support is there through controller / renderer but native DSD file output over HDMI support behind the times.
jo...@gmail.com <jo...@gmail.com> #46
Adding myself as someone wanting this feature.
ja...@gmail.com <ja...@gmail.com> #47
+1, especially with the new and more powerful Google TV coming out
an...@gmail.com <an...@gmail.com> #48
+1 really sad this doesn't already exist
mi...@axosoft.com <mi...@axosoft.com> #49
+1 please!
th...@gmail.com <th...@gmail.com> #50
+1 quality matters - often people rush to build next and next new fetures, but what is really needed is visible here as all these "+1" Anyone brave?
ja...@gmail.com <ja...@gmail.com> #51
Yes. I definitely need this too. Please...
ki...@gmail.com <ki...@gmail.com> #52
This would shift so many Android boxes tot he audiophile community please add it
ph...@gmail.com <ph...@gmail.com> #53
still not working with nvidia shield experience 9.0
ds...@gmail.com <ds...@gmail.com> #54
+1 from me - Android (and Shield) can be the obvious choice for audiophiles!
ke...@gmail.com <ke...@gmail.com> #55
+1 for me, I want to dump my Oppo 203 as it is the only media player that passes my DSD
al...@gmail.com <al...@gmail.com> #56
Please DSD is a must have. Android and Shiled is best streamer.....just missing DSD
mi...@gmail.com <mi...@gmail.com> #57
Please native HDMI DSD is a must have. Thank you.
an...@gmail.com <an...@gmail.com> #58
5 Years Now. It's been "assigned". I guess this is just never going to get done and total wishful thinking. Maybe it's not technically possible, but it's clearly not a priority. It's disappointing but understandable as it's a niche and dying format that has been neglected even by it's creator for several years.
bo...@gmail.com <bo...@gmail.com> #59
I don't agree that it's understandable. It's either in the development plan
or it isn't. A simple answer would do instead of wasting everyone's time.
Any other company would close the case sooner than later. The requirement
could always be added back in.
Crickets!
On Thu, Jun 22, 2023, 3:58 PM <buganizer-system@google.com> wrote:
or it isn't. A simple answer would do instead of wasting everyone's time.
Any other company would close the case sooner than later. The requirement
could always be added back in.
Crickets!
On Thu, Jun 22, 2023, 3:58 PM <buganizer-system@google.com> wrote:
an...@gmail.com <an...@gmail.com> #60
Oh, I agree there. I meant that it's understandable that it wouldn't be a
priority or even something they decided to do at all in Android. The amount
of people wanting DSD over HDMI probably just isn't enough to justify the
cost, time, and other resources necessary to implement this. It would be
better if they just outright said "not in our plans, and we don't foresee
doing this" rather than just letting it sit with no update for nearly 5
years. (More than 5 since the issue was created, close to 5 since it was
assigned to "ji...@google.com".
I actually don't know how much that would even require. But I know that the
entire android audio subsystem has been completely revamped in that time.
It would have been impossible to do before that. But even still, many
AndroidTV boxes like the nVidia Shield TV Pro, can't play multichannel
hi-rez audio back natively. There are some apps that can do it (like Kodi),
but I have several 5.1 albums in FLAC format, and Plex still can't play
them, which they claim is because they use the native Android audio
subsystems.
I have several SACDs that I've ripped to FLAC because finding a good SACD
player that plays over HDMI is hard enough at any kind of reasonable price.
But there's always loss in format conversion. Plus, I'd really just like to
not have to rely on changing physical disks and have native format digital
backups. Like, I have a whole stack of Elton John, Carpenters, Pink Floyd,
Spirit... And I have a PS3 to play them back (and that I use to rip them),
but those have pretty limited lifespans, first, but second, I would prefer
the slight loss in quality from the rip conversion. And then there's all
the features of having a system like Plex, Kodi, Jellyfin, etc. Like artist
info, background art, visualizers, and the whole library management aspect
sure is nice. And, again, it's getting really hard to find a solid,
affordable, SACD player.
But as much I want this, I am also in the software development field myself
and understand that is a pretty niche ask without much return on investment.
Then again, UAPP does it over USB, so maybe it's not really all that hard.
It would be nice to get an update. Even if it is just to say "nah, ain't
gonna happen".
On Thu, Jun 22, 2023 at 6:10 PM <buganizer-system@google.com> wrote:
priority or even something they decided to do at all in Android. The amount
of people wanting DSD over HDMI probably just isn't enough to justify the
cost, time, and other resources necessary to implement this. It would be
better if they just outright said "not in our plans, and we don't foresee
doing this" rather than just letting it sit with no update for nearly 5
years. (More than 5 since the issue was created, close to 5 since it was
assigned to "ji...@google.com".
I actually don't know how much that would even require. But I know that the
entire android audio subsystem has been completely revamped in that time.
It would have been impossible to do before that. But even still, many
AndroidTV boxes like the nVidia Shield TV Pro, can't play multichannel
hi-rez audio back natively. There are some apps that can do it (like Kodi),
but I have several 5.1 albums in FLAC format, and Plex still can't play
them, which they claim is because they use the native Android audio
subsystems.
I have several SACDs that I've ripped to FLAC because finding a good SACD
player that plays over HDMI is hard enough at any kind of reasonable price.
But there's always loss in format conversion. Plus, I'd really just like to
not have to rely on changing physical disks and have native format digital
backups. Like, I have a whole stack of Elton John, Carpenters, Pink Floyd,
Spirit... And I have a PS3 to play them back (and that I use to rip them),
but those have pretty limited lifespans, first, but second, I would prefer
the slight loss in quality from the rip conversion. And then there's all
the features of having a system like Plex, Kodi, Jellyfin, etc. Like artist
info, background art, visualizers, and the whole library management aspect
sure is nice. And, again, it's getting really hard to find a solid,
affordable, SACD player.
But as much I want this, I am also in the software development field myself
and understand that is a pretty niche ask without much return on investment.
Then again, UAPP does it over USB, so maybe it's not really all that hard.
It would be nice to get an update. Even if it is just to say "nah, ain't
gonna happen".
On Thu, Jun 22, 2023 at 6:10 PM <buganizer-system@google.com> wrote:
ve...@gmail.com <ve...@gmail.com> #61
You don't need to convert back to PCM, you can extract the ISOs you make with your PS3 to DSF files using SACD-Extract.
Since it's command line you can't even batch process your isos with a simple bash loop.
Recently Emby added support for DSF files and I've tested this over DLNA, you can bitstream DSD over LAN.
Gerbera can do this but I use here a custom version of Mini DLNA because it's faster for massive collections.
From there you have so many options to enjoy pure direct DSD.
My Denon is capable of receiving DSD over HDMI from the OPPO 203 but it's way easier to just use DLNA, use my phone and play the content on my receiver.
If you don't own a receiver capable of DSD there are many cheap options, the cheapest I can think is the LG G7 smartphone which has ESS quad (four paralleled) DACs ES9218P and if you are still on Android 9.0 it's capable of direct DSD playback without using the android driver and no PCM convertion.
Other cheap option is to just get a Topping DAC like the D10 and just have a raspberry pi running any form of headless debian/ubuntu and just use MPD (this is a pain to setup you but works on anything that runs linux and is capable of sending DSD over USB).
So there are many options around to still enjoy DSD, specially if you extract those from the ISOs.
If you don't, I believe Jriver on Windows and I'm sure the OPPO 203/205 running custom firmware can do it.
Better let this die, it's an ancient format and even if DSD over HDMI is added it is not even the most convinient way to enjoy this files and also won't allow for 5.1 DSD nor 5.6Mhz DSD and up because of HDMI limitations.
Since it's command line you can't even batch process your isos with a simple bash loop.
Recently Emby added support for DSF files and I've tested this over DLNA, you can bitstream DSD over LAN.
Gerbera can do this but I use here a custom version of Mini DLNA because it's faster for massive collections.
From there you have so many options to enjoy pure direct DSD.
My Denon is capable of receiving DSD over HDMI from the OPPO 203 but it's way easier to just use DLNA, use my phone and play the content on my receiver.
If you don't own a receiver capable of DSD there are many cheap options, the cheapest I can think is the LG G7 smartphone which has ESS quad (four paralleled) DACs ES9218P and if you are still on Android 9.0 it's capable of direct DSD playback without using the android driver and no PCM convertion.
Other cheap option is to just get a Topping DAC like the D10 and just have a raspberry pi running any form of headless debian/ubuntu and just use MPD (this is a pain to setup you but works on anything that runs linux and is capable of sending DSD over USB).
So there are many options around to still enjoy DSD, specially if you extract those from the ISOs.
If you don't, I believe Jriver on Windows and I'm sure the OPPO 203/205 running custom firmware can do it.
Better let this die, it's an ancient format and even if DSD over HDMI is added it is not even the most convinient way to enjoy this files and also won't allow for 5.1 DSD nor 5.6Mhz DSD and up because of HDMI limitations.
ph...@gmail.com <ph...@gmail.com> #62
Have you guys heard of Neutron player? apparently it can do multichannel SACD-ISO over UPnP or DLNA. I haven't tried it yet.. but apparently it works on Shield as well. I might give it a shot.
bo...@gmail.com <bo...@gmail.com> #63
Please confirm the following:
1. Emby now supports native DSF?
2. If the above is true then Android remains the gating factor that allows
Emby to play native DSF over HDMI on an Android device?
In my case a Shield Pro.
As mentioned below I too have a Marantz SR6013 receiver that will play
native DSF via DLNA. This can be controlled by both the receiver remote
control or a smartphone via the HEOS app which is preferred.
Question: it appears that the requested Android update is now more a
convenience given one connection, i.e. HDMI and an Android device resident
music library??
Also important is that via Emby both the music and video library can be
played through a common library. Today I separate my music library and
manage and access it through MinimServer via DLNA out to the Marantz
receiver. This step would obviously be eliminated.
On Fri, Sep 2, 2022, 8:27 PM <buganizer-system@google.com> wrote:
1. Emby now supports native DSF?
2. If the above is true then Android remains the gating factor that allows
Emby to play native DSF over HDMI on an Android device?
In my case a Shield Pro.
As mentioned below I too have a Marantz SR6013 receiver that will play
native DSF via DLNA. This can be controlled by both the receiver remote
control or a smartphone via the HEOS app which is preferred.
Question: it appears that the requested Android update is now more a
convenience given one connection, i.e. HDMI and an Android device resident
music library??
Also important is that via Emby both the music and video library can be
played through a common library. Today I separate my music library and
manage and access it through MinimServer via DLNA out to the Marantz
receiver. This step would obviously be eliminated.
On Fri, Sep 2, 2022, 8:27 PM <buganizer-system@google.com> wrote:
ve...@gmail.com <ve...@gmail.com> #64
Sorry if I didn't made myself clear.
Emby can play DSF from it's server over USB to a DAC.
Not HDMI.
I've tested it on ny topping d10.
You can see my chat with the Emby Team on their forums:
https://emby.media/community/index.php?/topic/110732-dsd-28mhz-sent-as-pcm-352-mhz/
Emby can play DSF from it's server over USB to a DAC.
Not HDMI.
I've tested it on ny topping d10.
You can see my chat with the Emby Team on their forums:
bo...@gmail.com <bo...@gmail.com> #65
tr...@gmail.com <tr...@gmail.com> #66
There are 2 reasons why I think this would be preferable to other methods:
1) The user experience would be better. For instance being able to use Kodi or Plex directly from an Nvidia Shield or similar would be easy and would have a nice and intuitive GUI compared to other solutions
2) I'm a big fan of multichannel DSD (DSF) audio and my receiver (Denon X8500) is not capable of handling this audio signal using DLNA. So I'm forced to use some other device like my Sony UBP 700 as a DLNA target. And that just isn't as easy as Kodi, Plex etc.
That being said I have actually decided that PCM works better for me because I want to use room correction (Audyssey Multeq-X) and that will be bypassed if I switch to Direct or Pure Direct on my receiver so I will be converting to PCM regardless and I guess it doesnt really matter if the receiver or my Android box does that... Still I'd like to have options
1) The user experience would be better. For instance being able to use Kodi or Plex directly from an Nvidia Shield or similar would be easy and would have a nice and intuitive GUI compared to other solutions
2) I'm a big fan of multichannel DSD (DSF) audio and my receiver (Denon X8500) is not capable of handling this audio signal using DLNA. So I'm forced to use some other device like my Sony UBP 700 as a DLNA target. And that just isn't as easy as Kodi, Plex etc.
That being said I have actually decided that PCM works better for me because I want to use room correction (Audyssey Multeq-X) and that will be bypassed if I switch to Direct or Pure Direct on my receiver so I will be converting to PCM regardless and I guess it doesnt really matter if the receiver or my Android box does that... Still I'd like to have options
vi...@google.com <vi...@google.com> #67
DSD is now directly supported on Android for USB.
Adding support for new formats for IEC61937 passthrough for HDMI is time consuming and difficult to implement in the Android framework. So we have decided to not add new formats in the framework for HDMI and to simply allow apps to write their own IEC61937 wrappers. The advantage of this is that IEC61937 will work on old versions of Android.
An app can determine whether a target device (TV) supports a particular format by examining the audio profiles and the raw EDIDs from the device. The raw EDIDs could be obtained using AudioDescriptor.
The code snippet as follow.
AudioDeviceInfo[] devices = AudioManager.getDevices(AudioManager.GET_DEVICES_OUTPUTS);
AudioDeviceInfo hdmiDevice = Arrays.stream(devices).filter(device ->
device.getType().equals(AudioDeviceInfo.TYPE_HDMI)).findAny().orElse(null);
AudioDescriptor desc = hdmiDevice.getAudioDescriptors().stream().filter(descriptor ->
descriptor.getStandard().equals(AudioDescriptor.STANDARD_EDID)).findAny().orElse(null);
byte[] rawEdid = desc.getDescriptor();
Description
Version used: all so far released
Devices/Android versions reproduced on: fugu (Google Nexus Player) // Oreo 8.0.0 (OPR2.170623.027, Nov 2017) and all previous fw revisions
The goal is to play DSD audio files (.dff, .dsf, .wv) using android player like:
BUT being able to feed the home audio amplifier / receiver via HDMI with a pristine and native DSD stream instead of PCM.
DSD transmission via HDMI is NOT done via High-Bitrate (HBR) Audio Stream Packetisation (conforming to IEC 60958/IEC 61937) as for all PCM-based audio formats but by a unique fashion described in the High-Definition Multimedia Interface Specification Version 1.2 and above:
5.3.9 One Bit Audio Sample Packet
One Bit Audio streams are transmitted using the One Bit Audio Sample Packet.
One Bit Audio Packets consist of one to four One Bit Audio Subpackets. These may be different
samples or different partial samples (e.g. 2 of 6 channels). The configuration of the Subpackets is
determined by the layout and samples_present bits in the header. This is described in detail in
Section 7.6, Audio Data Packetization.
It is optional for the Source, Sink and Repeater to support the One Bit Audio packet.
Table 5-24 One Bit Audio Packet Header
Byte \ Bit # 7 6 5 4 3 2 1 0
HB0 0 0 0 0 0 1 1 1
HB1 Rsvd
(0)
Rsvd
(0)
Rsvd
(0) layout samples_
present.sp3
samples_
present.sp2
samples_
present.sp1
samples_
present.sp0
HB2 Rsvd
(0)
Rsvd
(0)
Rsvd
(0)
Rsvd
(0)
samples_
invalid.sp3
samples_
invalid.sp2
samples_
invalid.sp1
samples_
invalid.sp0
• layout [1 bit] indicates which of two possible Subpacket/audio sample
layouts are used. See Table 5-25 below and Section 7.6, Audio Data
Packetization.
• samples_present.spX [4 fields, 1 bit each] indicates if Subpacket X contains audio sample
data. Samples_present.spX = 1 if subpacket X contains sample data;
else = 0.
• samples_invalid.spX [4 fields, 1 bit each] indicates if Subpacket X represents invalid
samples. Samples_invalid = 1 if the samples in Subpacket X are
invalid; else = 0. This bit is only valid if the relevant
“samples_present.spX” is set.
Note that, for One Bit Audio, sample frequency information is carried in the Audio InfoFrame (see
section 8.2.2).
Table 5-25 One Bit Audio Subpacket
Byte \ Bit # 7 6 5 4 3 2 1 0
SB0 ChA.7 - - - - - - ChA.0
SB1 ChA.15 - - - - - - ChA.8
SB2 ChA.23 - - - - - - ChA.16
SB3 ChB.7 - - - - - - ChB.0
SB4 ChB.15 - - - - - - ChB.8
SB5 ChB.23 - - - - - - ChB.16
SB6 ChB.27 ChB.26 ChB.25 ChB.24 ChA.27 ChA.26 ChA.25 ChA.24
• ChA.X: [28 fields, 1 bit each] indicates consecutive One Bit Audio samples of the first
channel. The most significant bit (ChA.27) is the first sampled bit of the consecutive 28-bit
part in the One Bit Audio stream.
• ChB.X: [28 fields, 1 bit each] indicates consecutive One Bit Audio samples of the
second channel. The most significant bit (ChB.27) is the first sampled bit of the
consecutive 28-bit part in the One Bit Audio stream.
7.3.1 One Bit Audio Sample Rate Requirements
A Source may transmit One Bit Audio at an fS (1/64th of the bit rate) of 32kHz, 44.1kHz, 48kHz,
88.2kHz, 96kHz, 176.4kHz or 192kHz. Any Source capable of supporting One Bit Audio should
support an fS of 44.1kHz, corresponding to a bit rate of 2.8224MHz.
Transmitted One Bit Audio shall have an audio sample rate within ±1000 ppm of the targeted
sample rate, except when the Source is Audio Rate Controlled by CEC (see section 7.11).
A Sink may accept One Bit Audio at an fS (1/64th of the bit rate) of 32kHz, 44.1kHz, 48kHz,
88.2kHz, 96kHz, 176.4kHz or 192kHz. Any Sink capable of supporting One Bit Audio shall support
an fS of 44.1kHz, corresponding to a bit rate of 2.8224MHz.
For One Bit Audio, sample frequency information is carried in the Audio InfoFrame (see section
8.2.2).
7.6.1 One Bit Audio Packetization
When transmitting One Bit Audio, each Subpacket shall contain One Bit Audio bits for zero, one or
two audio channels.
There are four sample_present bits in the One Bit Audio Sample Packet Header, one for each of
the Subpackets. The corresponding bit is set if that Subpacket contains audio samples. There are
four samples_invalid.spX bits which are set if no useful audio data was available at the Source
during the time period represented by that sample. When samples_invalid.spX is set, Subpacket X
continues to represent a sample period but does not contain any useful data.
Layout 0 can be used to carry 2 channels of One Bit Audio samples. Layout 1 can be used to carry
from three to eight channels of One Bit Audio samples.
7.9 One Bit Audio Usage Overview
One Bit Audio data is transmitted using the One Bit Audio packet defined in section 5.3.9 and
described in section 7.6.1.
One Bit Audio clock regeneration uses the same mechanism used for all audio on HDMI and is
described in section 7.2.4. One Bit Audio sample rate requirements are described in section 7.3.1.
A Sink may indicate its support for One Bit Audio with the Short Audio Descriptor as described in
section 8.3.6.
One Bit Audio uses some fields within the Audio InfoFrame differently than L-PCM or compressed
audio; these differences are described in section 8.2.2.
U+1F596