Posts by NSXD

Quote from Da Flex

A/V is in-sync on Kodi, because it's played on the same stream, and gets buffered without low-latency conditions. So I don't talk about personal pronouns, but about the concept of Kodi. ASIO breaks that concept, because it gives audio highest priority.

I don't understand what are you talking about. Kodi/LE is using ALSA. Isn't it? ALSA supports everything we need. The kernel too.

But lets assume Kodi uses something very special within the ALSA Driver model for its A/V.

What do we care about A/V when we tap on "MUSIC"? There is no V or something we want to keep in-sync.

Quote from adelias

https://github.com/lintweaker/xmos-native-dsd/issues/41

Quote from adelias

You keep referring to lintweakers github page, are you aware that the info there is a decade old?
Also ALSA 1.0.29 was released in 2015.

Yes exactly.

What does this say to us?

Quote from Da Flex

If you don't need ASIO, stay away from it. In addition to the above points (#28), LE is no low-latency OS, so it makes zero sense.

You need to avoid personal pronouns in such kind of discussions. We don't talking about personal preferences but about a broader class of devices, which are obviouly out of focus and therefore ignored.

Kodi has its origins in playing of all sorts video-oriented content. That is clear and led to many uselul things like a sophisticaed and well implemented menu navigation.

But maybe its time to take a closer look on the audio part.

Quote from Da Flex

Yes. The ALSA part of the Linux kernel can handle standard ASIO. That's why my Behringer UMC22 is working.

I don't think that all the fuss is about ASIO it self.

My guess is that the special ASIO Driver chosen for Windows is only serving as a means to an end. In other words, to activate this alternate setting provided by XMOS.

Since is is stated that this feature "Will be generally available with the next ALSA release (1.0.29)" it makes no sense to talk about ASIO and its special Windows driver.

https://github.com/lintweaker/xmos-native-dsd states clearly that with that alternate setting provided by ALSA release (1.0.29) the things are are working out.

Quote from chewitt

ASIO is Windows only. There's no direct equivalent to ASIO on Linux (only good-old ALSA) but I do see folks in the RPi audio distro ecosystem using RT (real-time) kernels because that's supposed to be better juju for your listening experience. Magic

As far as I understand ALSA already supports the alternate setting to playback native DSD on XMOS based devices. In Windows this necessary feature is supported by the ASIO driver provided by the manufacturer.

Please read: https://github.com/lintweaker/xmos-native-dsd

Quote from Da Flex

As mentioned a couple of times, I think the proprietary ASIO driver is the problem. There is no need for ASIO on music playback. So I suggest using a DAC without ASIO. This one should work on Linux:

Please read: https://github.com/lintweaker/xmos-native-dsd

ALSA seems to be able to do what the Windwos ASIO driver is doing (supporting an alternate setting on the XMOS USB Controller)

Quote from noggin

Totally get the need for low-latency for music production (where you're often recording and playing simultaneously and need everything to stay in-sync) - I work in broadcast for my day job so totally understand the challenges of low-latency and the need for it in a production context.

However I'm slightly puzzled by the need for the low-latency (and thus drivers that support it) in a purely playback setting where you just hit play and listen? Having some latency between hitting play and the music starting could be annoying (and if it's excessive and not accommodated for gapless playback I get that could be annoying) - but unless low-latency has another aspect I'm missing I'm not sure I see the need?

Isn't ASIO specifically a Windows thing - not sure I get how it's related to Linux? Or am I missing something?

I agree with you.

It would be useful to display some information about which audio codec is used, when certain headphones, speaker etc. are connected via Bluetooth wirelessly. Show which codecs are available/usable on that connection and probably the ability to choose a codec of preference.

Quote from Da Flex

MPD is an add-on for LE. If you can install LE on that tablet, you can also install the add-on.

I know that MPD can be installed as add-on but as far as I understand it is a server/client application. Is server and client running on the same device? Or how is the user achieving its DSD Playback.

I read tht Volumio is using MPD for its DSD Playback. Gave it a try one week ago. GUI and functionality is somewhat simple but DSD is indeed working without further doing.

Quote from Da Flex

Which tablet do you want to use, and what do you want to achieve on it?

It shall become mainly a music media center. The other things Kodi has to offer in addition are nice & usable too. Otherwise I wouldn't waste so much time on that topic.

Quote from adelias

I'm using mpd from the libreelec repository. mpd has supported DSD for many years. It can play

up to DSD512 with my USB DAC (SMSL DL200).

Is MPD working on a standalone Tablet PC without further hardware?

Quote from noggin

I don't know what the Linux support is for DSD64-512 native audio transport over USB - either as DSD Native or carried as DSD-over-PCM.

There is some information on https://github.com/lintweaker/xmos-native-dsd. from 2019. It does not seem impossible and over the last 5 years there maybe further development and insights into that matter.

I know that some apps like the Fiio Music App on Android are working flawlessly (PCM/DSD) no matter from which manufacturer the devices are made (Yamaha, Fiio, Topping, whatever). USB ID don't seems to matter. And as I said above all these devices are using XMOS USB Controller at their Input.

Native DSD support for XMOS based devices

XMOS based USB DACs and converters can support native DSD playback using a 32-bit sample format. DACs that support this feature expose it using a Alternate Setting on the USB interface.

On Windows systems this feature can be used with a ASIO 2.1/2.2 driver from the DAC manufacturer.

I have added a new DSD sample format to ALSA and the Linux kernel (DSD_U32_LE) to support it on Linux and added the needed quirks to support it for a few XMOS based USB DACs/boards.

Currently native DSD playback on Linux is supported for the following XMOS based DACs/USB converters:

• iFi Audio micro iDSD [max DSD512]
• iFi Audio nano iDSD [max DSD256, with latest 4.04 firmware]
• DIYINHK USB to I2S/DSD converter [max DSD128]
• ..more to follow

ALSA support status:

• New DSD sample format accepted, code resides in ALSA development git
• Will be generally available with the next ALSA release (1.0.29)

Kernel support status:

• Kernel 3.18rc1 contains the needed new sample format support
• Kernel 3.18rc1 supports the iFi Audio and DIYINKHK devices

Linux Playback support:

• python scripts [python-dsd-tools] (https://github.com/lintweaker/python-dsd-tools)
• MPD support (0.18-dsd). See [mpd-dsd-018] (https://github.com/lintweaker/mpd-dsd-018)

Quote from noggin

NB I'm not making any claims for DSD audio being better or worse than PCM audio, nor am I making any claims that DSD512 is better than 48k/16bit audio - but I know for some people it's important...

Yes. Some of these DACs are quite expensive and sophisticated in an audiophile way. And people don't want some OS or Software to fiddele with the original data. People also want their displays, indicators to work correctly.

Quote from Da Flex

The USB audio interface was made for musicians, so the input/output timing has to be low-latency. That requires a specific ASIO driver. That driver is incomplete on Linux, so he only gets 44.1kHz.

That information isn't up to date and that kind of devices aren't made for musicians but for high end audio reproduction (audiophile).

There is/was a sample rate limitation setting in the hidden "Expert" Settings. When the limitation setting is set to it's maximum value of 384 kHz, High-Resolution files seem to be transported at their native sample rate. DSD Files are being converted accordingly to 384 kHz.

Quote from noggin

What Yamaha amplifier do you have ?

I take it from your post that it has a USB connector that will appear to connected devices as a USB DAC for both PCM and DSD audio? If you find out the USB IDs for it that may help?

All that kind of devices no mater from which manufacturer are using the same technology/concept. There is XMOS USB controller sitting at the entrance followed by one or even two D/A converters for left and right channel separately (mostly ESS Sabre or sometimes Akashi AKM).

Quote from Da Flex

In short: You want to use a USB audio interface, connect it to the AVR over S/PDIF, and play native DSD.

No!!!

Main purpose of that kind of equipment is to provide highest grade of analog signal possible. It is connected to an high quality analog headphone or stereo amplifier.

The S/PDIF Out is just an addon, which may become handy sometimes.

No one would come up with the idea to spend hundreds or even thousands of Dollars to use that kind of equipment as a simple USB to S/PDIF Converter. Meaning and purpose is a High-End Digital to Analog conversion. Nothing else.

...

Quote from Da Flex

Theory: I think the problem is the proprietary ASIO driver of your USB audio interface.

The proprietary ASIO driver is just a solution for Windows in order to bypass the Window's own Audio Engine which have certain advantages in combination whith Foobar.

The proprietary ASIO isn't needed for Linux or Android and also in Windows WSAPI in exclusive Mode shall work, the say.

...

I think the problem is a completely different one. That kind of Interfaces just expecting raw data in PCM or DSD (see specs above). There should be no magic to feed them by just passing the data from the files to the interface.

With one exception...

Since not all audio is saved are PCM or DSD Files an additional layer is needed to unpack or convert files like FLAC or MP3 etc. to PCM. ...This job I guess is already done by FFMPEG.

That means we just need a Conrolbox "USB DAC Direct" which is passing the data

1. from PCM/DSD Files directly to the Interface

2. from other Formats via FFMPEG as PCM to the Interface.

By providing an "USB DAC Direct" Mode there is no reason for LibreELEC to pass DSD Files through FFMPEG for convertion to PCM. Just let the USB Interface and its High End DAC do the job it is intended to do... namely convert PCM and DSD Data into an analog signal.

For compatibility reasons and DSD there could be an additional Option for packaging native DSD Data from the Audiofiles into PCM Chunks for "DSD over PCM" (DoP). That kind of interfaces can play usually both or at least one of them.

Since not all Audio Files are in PCM or DSD but compressed in Flac which

I read the topics above but the things become fancy and offering no practicable solutions or are got even closed before somebody could explain e.g. how the ffmpeg patch mentioned in some thread could be applied.

Lets take a look on a common setup and what millions people are doing or in our case trying to do with LibreELEC:

As you may see there is no fancy stuff involved like Rapsberries, servers and clients etc. but just a Tablet PC as Media Center and a simple Digital to Analog Converter connected by USB to the tablet PC.

Main goal is to get the audio files injected direct resp. native in to the Digital to Analog Converter.

In Windows the manufacturer of such Digital to Analog Converters decided to utilize a proprietary ASIO driver made by some German company.

Main reason for this is to circumvent the whole Windows Audio Engine by using Foobar in combination with that proprietary ASIO driver. That ensures the Windows Audio Engine have no impact on the data feeded to the DAC especially when all sorts of settings are set in Windows.

1.

As far as I understand XMOS is supported and native DSD support possible as long as the hardware is recognised by her USB ID provided in that "C" file above.

2.

Since my DSD Files are converted to 44.1kHz PCM, I have to asume, that my YAMAHA Amplifier is not registered in that list by his USB ID.

Is there any easy way to provide LibreElec with the YAMAHA USB ID without the need to compile the whole distribution?