![]() ![]() ![]() ![]() If your driver isn't working, use the driver having the same OEM with the your laptop/desktop brand name. If you are looking for an update, pickup the latest one. With the different devices, they can have the same driver, it's because they all use the same chip manufacturer. Just my 2 cents, maybe I have overlooked something.Below is a list of drivers that may be suitable for your device. The SPDIF output in linux is "guessed" by the alsa config - since the device is not blacklisted in /usr/share/alsa/cards/nf, the iec958 PCM device is generated and subsequently recognized by KODI. IMO windows cannot offer SPDIF output because the device itself reports no SPDIF output, IMO. So I do not know how these are delivered to the chip (if at all). Neither found any mention of that in the register documentation posted in this thread (but that was I2C access IIUC). It simply reads the alsa PCM device name and if it finds spdif or iec958 substring, it marks the device as AE_DEVTYPE_IEC958 xbmc/AESinkALSA.cpp at a0d424ec8f1050b29c2233e57952c20f1c63c993 * xbmc/xbmc * GitHub which gets reported in that dump in xbmc/AEDeviceInfo.cpp at a80d1293b0579bbed7dd7d20304ba34a20519f78 * xbmc/xbmc * GitHubĪs of the AES SPDIF preamble controls - I could not find any way to pass them to the chip through USB. Otherwise it behaves just like a regular PCM device (which it is). Please notice that all the iec958 config does is define the name (iec958 = spdif) and configure the AES preamble bits for the SPDIF transmitter. If a device is not listed here (which the CM6632 is not), the general SPDIF config for device 0 is applied from general file /usr/share/alsa/pcm/nf. Section 958_device defines special PCM devices for SPDIF output - some have device 1 (those with an extra audio interface for SPDIF), some have none (those with the device 999 set by that config). USB audio cards use file /usr/share/alsa/cards/nf which configures many PCM devices (those listed by aplay -L). Alsa comes with config files in /usr/share/alsa. The device reports only one output terminal (of type "speaker"), it reports nothing about a dedicated output terminal of type SPDIF (which the standard defines but very few devices actually use). Sample formats natively supported: PCM 16bit, 24bit, 32bit (bmFormats is 0x00000001) and the 64 bit SPECIAL format with bmFormats 0x80000000 meaning raw data - DSD?ĭata sent every 125us which minimizes latency. The stream0 file is more descriptive, lsusb gives extra details. The dumps are identical for ubuntu and openelec, with ubuntu having newer kernel/userspace which got improved info reports slightly. But the lsusb and stream0 dumps show all we need. You would see the values during playback. When nothing is being played, the device is closed. Why Windows can't handle SPDIF passthrough? Is it due to poor Windows drivers? The first (Default) output has 'No passthrough capabilities' the second 'Digital Output (S/PDIF)' can send streamTypes: STREAM_TYPE_AC3, STREAM_TYPE_DTSHD_CORE, STREAM_TYPE_DTS_1024, STREAM_TYPE_DTS_512, STREAM_TYPE_DTS_2048. M_streamTypes : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_512,STREAM_TYPE_DTS_2048The difference is deviceType (PCM vs. M_displayNameExtra: Digital Output (S/PDIF) M_displayName : CM6631A Audio Processor Digital Stereo (IEC958) M_deviceName : alsa_b-C-Media_Electronics_Inc._USB2.0_High-Speed_True_HD_Audio-00.iec958-stereo M_streamTypes : No passthrough capabilities M_displayNameExtra: Default Output Device ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |