A very good document on introduction of digital sampling:
Introduction to Digital Filtering with Audio Application
https://ccrma.stanford.edu/~jos/filters/filters.htm
Showing posts with label Playback Technology. Show all posts
Showing posts with label Playback Technology. Show all posts
15 Dec 2009
25 Nov 2008
Dither - Definition
http://www.weiss-highend.ch/medea/documents/medea_manual_000.pdf
"Suppose a digital recording has been made with a 24 bit A/D converter and a 24
bit recorder. Now this recording should be transferred to a CD which has just 16 bits per sample,
as you know. What to do with those 8 bits which are too many?
The simplest way is to cut them off, truncate them. This, unfortunately, generates harmonic distortions at low levels, but which nonethless cause the audio to sound harsh and unpleasant. The harmonic distortion is generated because the eight bits which are cut off from the 24 bits are correlated with the audio signal, hence the resulting error is also correlated and thus there are distortions and not just noise (noise would be uncorrelated). The dithering technique now is used to de-correlate the error from the signal.
This can be achieved by adding a very low level noise to the original 24 bit signal before
truncation. After truncation the signal does not show any distortion components but a slightly
increased noise floor. This works like magic..... the distortion is replaced by a small noise – much
more pleasant."
"Suppose a digital recording has been made with a 24 bit A/D converter and a 24
bit recorder. Now this recording should be transferred to a CD which has just 16 bits per sample,
as you know. What to do with those 8 bits which are too many?
The simplest way is to cut them off, truncate them. This, unfortunately, generates harmonic distortions at low levels, but which nonethless cause the audio to sound harsh and unpleasant. The harmonic distortion is generated because the eight bits which are cut off from the 24 bits are correlated with the audio signal, hence the resulting error is also correlated and thus there are distortions and not just noise (noise would be uncorrelated). The dithering technique now is used to de-correlate the error from the signal.
This can be achieved by adding a very low level noise to the original 24 bit signal before
truncation. After truncation the signal does not show any distortion components but a slightly
increased noise floor. This works like magic..... the distortion is replaced by a small noise – much
more pleasant."
5 Sept 2008
Digital Domain FAQ
A very good forum with many information on professional digital audio knowledge:
http://www.digido.com/faq.html
http://www.digido.com/faq.html
1 Jul 2008
CICS player
For those who are familiar with computer settings, computer expert and audiophile "cics" offers 3 free tools for us audiophiles who further enhances our playback sound quality. These tools are:
(1) The Art of Building Computer Transport:
(2) cMP mini OS :
(3) cplay Minimalist Player
(1) The Art of Building Computer Transport:
- XP SP2 optimization at system level. Disable all unnecessary computer components in order to achieve highest playback performance
- http://www.audioasylum.com/cgi/t.mpl?f=pcaudio&m=19242
(2) cMP mini OS :
- Turns XP into a simple player, and only the default music player (foobar, wimamp) is usable
- http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=27041
(3) cplay Minimalist Player
- A Minimalist music player created purely to achieve best sound quality. Now at version b19. Not all versions sound the same but b19 offers highest resolution up till now. You may choose other version which have different sound charcteristics:
- Download: http://sourceforge.net/project/showfiles.php?group_id=226826&package_id=274544
- Main Page: http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=31286
1 Jun 2008
Cics Player
Cicsplay is an excellent player with very high fidelity. I have used it to replace Foobar.
However, due to the RAM playback characteristics, it can only playback one song. I have written some very primitive Visual Basic (2008) code to playback a m3u playlist .
-------------------------------
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
FileOpen(1, "C:\cics.m3u", OpenMode.Input)
Dim trackname As String
Dim myProcess As Process = New Process
myProcess.StartInfo.FileName = "C:\Progra~1\cicspl~1\cicsPlay.exe"
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Minimized
Do Until EOF(1)
trackname = "C:\" & LineInput(1)
myProcess.StartInfo.Arguments = trackname
myProcess.Start()
myProcess.WaitForExit()
myProcess.Close()
Loop
FileClose()
End Sub
End Class
However, due to the RAM playback characteristics, it can only playback one song. I have written some very primitive Visual Basic (2008) code to playback a m3u playlist .
-------------------------------
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
FileOpen(1, "C:\cics.m3u", OpenMode.Input)
Dim trackname As String
Dim myProcess As Process = New Process
myProcess.StartInfo.FileName = "C:\Progra~1\cicspl~1\cicsPlay.exe"
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Minimized
Do Until EOF(1)
trackname = "C:\" & LineInput(1)
myProcess.StartInfo.Arguments = trackname
myProcess.Start()
myProcess.WaitForExit()
myProcess.Close()
Loop
FileClose()
End Sub
End Class
6 Apr 2007
Kmixer and Direct Sound
http://msdn2.microsoft.com/en-us/library/bb219700.aspx
DirectSound Driver Models
Under the VXD driver model, all DirectSound mixing is done in Dsound.vxd, a virtual device driver. Dsound.vxd also provides close access to the actual DMA buffer that the sound card uses to receive data from the host CPU. This is the same as the DirectSound primary buffer. A DirectSound application can set specific properties of the primary buffer, such as sampling rate and bit depth, thus changing the properties of the hardware itself.
Under the Windows Driver Model (WDM), DirectSound does not have direct access to the sound hardware, except in the case of hardware-accelerated buffers. Instead, DirectSound sends data to the kernel mixer. The kernel mixer's job is to convert the format of multiple audio streams to a common format, mix them together and send the result to the hardware. In a sense, it does what Dsound.vxd does. One major difference is that Dsound.vxd mixes only DirectSound buffer data, but the kernel mixer mixes all Windows audio data, including data from applications that use the Win32 waveOut functions. The rule that DirectSound and the waveform-audio output device cannot both be open at the same time is not true on systems with WDM drivers.
Of particular importance is the kernel mixer's relationship with the audio hardware. the kernel mixer is the only software on the system that can specify the format of the hardware's DMA buffer. It selects the format on the basis of sounds it is asked to mix. It sets the output format to the highest-quality format of sounds that it is asked to mix, or to the closest format to this that the hardware supports.
This has one very important implication: DirectSound cannot set the format of the hardware's DMA buffer. For your application, this means that the hardware format is based on the data you actually play. If you play a 44 kHz file, Kmixer will mix all data up to 44 kHz and ensure that the hardware is running at 44 kHz.
As an application developer, you don't choose the driver model used. That is completely determined by the type of sound card, the version of Windows, and the installed driver. For this reason, it is very important that you cover all possibilities when you test your application. DirectSound might be using Dsound.vxd or it might be using the kernel mixer, and you should ensure that your application's behavior and performance are acceptable on both.
DirectSound Driver Models
Under the VXD driver model, all DirectSound mixing is done in Dsound.vxd, a virtual device driver. Dsound.vxd also provides close access to the actual DMA buffer that the sound card uses to receive data from the host CPU. This is the same as the DirectSound primary buffer. A DirectSound application can set specific properties of the primary buffer, such as sampling rate and bit depth, thus changing the properties of the hardware itself.
Under the Windows Driver Model (WDM), DirectSound does not have direct access to the sound hardware, except in the case of hardware-accelerated buffers. Instead, DirectSound sends data to the kernel mixer. The kernel mixer's job is to convert the format of multiple audio streams to a common format, mix them together and send the result to the hardware. In a sense, it does what Dsound.vxd does. One major difference is that Dsound.vxd mixes only DirectSound buffer data, but the kernel mixer mixes all Windows audio data, including data from applications that use the Win32 waveOut functions. The rule that DirectSound and the waveform-audio output device cannot both be open at the same time is not true on systems with WDM drivers.
Of particular importance is the kernel mixer's relationship with the audio hardware. the kernel mixer is the only software on the system that can specify the format of the hardware's DMA buffer. It selects the format on the basis of sounds it is asked to mix. It sets the output format to the highest-quality format of sounds that it is asked to mix, or to the closest format to this that the hardware supports.
This has one very important implication: DirectSound cannot set the format of the hardware's DMA buffer. For your application, this means that the hardware format is based on the data you actually play. If you play a 44 kHz file, Kmixer will mix all data up to 44 kHz and ensure that the hardware is running at 44 kHz.
As an application developer, you don't choose the driver model used. That is completely determined by the type of sound card, the version of Windows, and the installed driver. For this reason, it is very important that you cover all possibilities when you test your application. DirectSound might be using Dsound.vxd or it might be using the kernel mixer, and you should ensure that your application's behavior and performance are acceptable on both.
16 Mar 2007
MME, WDM, Vista moved audio driver from Kernel to User mode - A Short History
http://blogs.msdn.com/larryosterman/archive/2005/09/19/471346.aspx
The Windows audio system debuted in Windows 3.1 with the "Multimedia Extensions for Windows", or MME APIs. Originally, only one application at a time could play audio, that was because the original infrastructure didn't have support for tracking or mixing audio streams (this is also why the old audio apps like sndrec32 pop up an error indicating that another device is using the audio hardware when they encounter any error).
When Windows 95 (and NT 3.1) came out, the MME APIs were stretched to 32 bits, but the basic infrastructure didn't change - only one application could play audio at one time.
For Windows 98, we deployed an entirely new audio architecture, based on the Windows Driver Model, or WDM. As a part of that architectural change, we added the ability to mix audio streams - finally you could have multiple applications rendering audio at the same time.
There have been numerous changes to the audio stack over the years, but the core audio architecture has remained the same until Vista.
Over the years, we've realized that there three major problem areas with the existing audio infrastructure:
(1) The amount of code that runs in the kernel (coupled with buggy device drivers) causes the audio stack to be one of the leading causes of Windows reliability problems.
(2) It's also become clear that while the audio quality in Windows is just fine for normal users, pro-audio enthusiasts are less than happy with the native audio infrastructure. We've made a bunch of changes to the infrastructure to support pro-audio apps, but those were mostly focused around providing mechanisms for those apps to bypass the audio infrastructure.
(3) We've also come to realize that the tools for troubleshootingaudio problems aren't the greatest - it's just too hard to figure out what's going on, and the UI (much of which comes from Windows 3.1) is flat-out too old to be useful.
Back in 2002, we decided to make a big bet on Audio for Vista and we committed to fixing all three of the problems listed above.
The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver).
The second major change we made was a totally revamped UI for audio. Sndvol32 and mmsys.cpl were completely rewritten (from scratch) to include new, higher quality visuals, and to focus on the common tasks that users actually need to do. All the old functionality is still there, but for the most part, it's been buried deep below the UI.
The Windows audio system debuted in Windows 3.1 with the "Multimedia Extensions for Windows", or MME APIs. Originally, only one application at a time could play audio, that was because the original infrastructure didn't have support for tracking or mixing audio streams (this is also why the old audio apps like sndrec32 pop up an error indicating that another device is using the audio hardware when they encounter any error).
When Windows 95 (and NT 3.1) came out, the MME APIs were stretched to 32 bits, but the basic infrastructure didn't change - only one application could play audio at one time.
For Windows 98, we deployed an entirely new audio architecture, based on the Windows Driver Model, or WDM. As a part of that architectural change, we added the ability to mix audio streams - finally you could have multiple applications rendering audio at the same time.
There have been numerous changes to the audio stack over the years, but the core audio architecture has remained the same until Vista.
Over the years, we've realized that there three major problem areas with the existing audio infrastructure:
(1) The amount of code that runs in the kernel (coupled with buggy device drivers) causes the audio stack to be one of the leading causes of Windows reliability problems.
(2) It's also become clear that while the audio quality in Windows is just fine for normal users, pro-audio enthusiasts are less than happy with the native audio infrastructure. We've made a bunch of changes to the infrastructure to support pro-audio apps, but those were mostly focused around providing mechanisms for those apps to bypass the audio infrastructure.
(3) We've also come to realize that the tools for troubleshootingaudio problems aren't the greatest - it's just too hard to figure out what's going on, and the UI (much of which comes from Windows 3.1) is flat-out too old to be useful.
Back in 2002, we decided to make a big bet on Audio for Vista and we committed to fixing all three of the problems listed above.
The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver).
The second major change we made was a totally revamped UI for audio. Sndvol32 and mmsys.cpl were completely rewritten (from scratch) to include new, higher quality visuals, and to focus on the common tasks that users actually need to do. All the old functionality is still there, but for the most part, it's been buried deep below the UI.
25 Dec 2006
HTPC Advanced Topics
General description about spdif http://www.epanorama.net/documents/audio/spdif.html
General description about USB http://www.epanorama.net/links/pc_interface.html#general
spdif vs usb http://www.interfacebus.com/SPDIF_Audio_Interface.html
Audiophile 評論 digital audio trend http://www.positive-feedback.com/Issue22/nugent.htm
General description about USB http://www.epanorama.net/links/pc_interface.html#general
spdif vs usb http://www.interfacebus.com/SPDIF_Audio_Interface.html
Audiophile 評論 digital audio trend http://www.positive-feedback.com/Issue22/nugent.htm
Subscribe to:
Posts (Atom)
