Regarding software, its not hardware. DACs are hardware. DSP is math, although it is generally implemented in some kind of hardware (even if pencil and paper such as the old graphical DFTs).
There is nothing analogue about software, so you can't make a digital-to-analogue converter in software. What you can do in software is to simulate a DAC, or to preprocess digital signals such that you can use a much simpler DAC (even as simple as a flip-flop with a clean supply and a resistor as DAC).
From the answer, "The bit rate is the amount of information that is conveyed at each sample." This is hugely misleading. MP3 file compression does indeed "reduce the amount of information" overall, but it does not reduce the number of bits at each sample. mp3 does have a lower data rate than uncompressed PCM (.wav or CD), but the compression is done in a complex way over a series of samples.
Maybe so. Its sort of mixing the idea of samples (think PCM coding) which are measured in samples per second, as verses the concept of information flow which is measured in bits per second. A lot depends on how data is coded. Suppose we want to send music through a channel of limited bandwidth. One very lossy way might be to encode it as MIDI data along with text of any lyrics. At the receiving end the music can be 'decoded' and played. Of course, it would be
considered 'low quality' by some listeners. Mp3 requires an encoder and a decoder before it can be reconstituted into a PCM stream which then has the property of sample rate. Therefore may be easier to do a different calculation, say, find the bitrate of 16/44 PCM.
Last edited:
Let me elaborate on what I mean. The data in a .wav file can be extracted and displayed as numbers on a screen. This is not analog, it is still in digital format.
For example, I have taken created a 440 Hz sine wave in Audacity and exported it to .wav. Next, I have used a Python script to read the .wav file and to extract its data; the 'music'
see https://www.diyaudio.com/community/threads/mp3-data-viewing-software.380945/#post-6889972
Python:
import wave , struct
obj = wave.open('Track1.wav','r')
print( "Number of channels",obj.getnchannels())
print ( "Sample width",obj.getsampwidth())
print ( "Frame rate.",obj.getframerate())
print ("Number of frames",obj.getnframes())
print ( "parameters:",obj.getparams())
obj.close()
wavefile = wave.open('sine440.wav','r')
length = wavefile.getnframes()
for i in range(0, 10000 ):
wavedata = wavefile.readframes(1)
print(wavedata[1])Output (first few lines)
Charted in a spreadsheet (stereo is represented, hence the odd split, forced to mono it would be more like a sine wave I would think)
Now it is possible to use these numbers as a basis for creating analog signals, like a tone generator. In between, the data can be processed using software.
.wav file >> software >> text on screen/ on a file >> manipulation of data >> audio generated from data.
Does this constitute a DAC or a DSP? I am not quite sure. Is it a DAC with part of its function being performed through software? Are music players like this?
Sounds more like digital signal processing to me. The part where you generate analogue signals from the numbers is digital to analogue conversion, but I don't see how you could do that part in software.
I think you interpret signed numbers in two's complement notation as unsigned numbers, hence the gross distortion.
I think you interpret signed numbers in two's complement notation as unsigned numbers, hence the gross distortion.
Last edited:
Its not a dac. Its not hardly DSP either. Music players are much more complicated than you are thinking.
A music player is a piece of software that accepts inputs and sends outputs. Inputs devices are mouse, keyboard, wav file, etc. Outputs are video monitor and dac.
An audio dac outputs a voltage, not a picture. The voltage changes fast so measuring it requires an oscilloscope. The voltage signal can be plugged into the input jack on an audio amplifier, then the amplifier output can be connected to a speaker.
DSP is math that is mostly implemented with addition and multiplication operations. When you open a wav file as an input device, copy its numerical data to computer memory, that is simply input processing. DSP might involve mathematical operations to change volume, panning, tone, sample rate, etc. Merely reading file contents into memory and then displaying the numbers on a video monitor output device would not typically be considered DSP.
Opening a wav file, reading the data, and displaying it as a picture on a video monitor might be considered more like sending audio data to a video dac. A video dac used to be needed to produce analog electrical voltages sent to an analog CRT monitor in order for the CRT to display a picture. The video dac output is a voltage that changes very fast so an oscilloscope would be needed to view it.
So far you have not gotten to the point of producing an analog electrical voltage to feed into an audio amplifier, right?
Hopefully things are starting to become more clear by this point 🙂
Last edited:
Regarding the reading of audio files, it can be very useful to understand the low level organizational structure for a particular file type. For example, maybe nice to have if trying to figure out why a simulated oscilloscope view of wav file audio data might come out distorted. Attached is some info about wav files.
One thing I never understood about audio streaming is how crystal tolerances are handled. If the DAC's sample rate is derived from a crystal in the DAC or in the receiving computer while the ADC's sample rate is derived from a crystal on the sending side, you either need to have an asynchronous sample rate converter somewhere or have to repeat or drop samples every now and then.
I've asked the question before and got replies, but none that I could understand.
I've asked the question before and got replies, but none that I could understand.
For mixed clock domain streaming there are basically two options, ASRC or FIFO. In the latter case the FIFO buffer is reset during periods of silence, and the buffer length is long enough so that in under normal conditions the buffer never underruns or overruns. If clocks are too far out of sync the buffer can be set for a longer delay to help prevent chances of a dropout.
Most radio stations try to avoid periods of silence and manage to stream their signals anyway. You wrote "For mixed clock domain streaming", does that mean there is also non-mixed clock domain streaming, where the DAC is somehow adjusted to the sending computer's clock?
Not aware of a crystal reference dac that is adjusted to a computer clock. Perhaps there could be computer clocks adjusted to sync with multiple local dac clocks within some average dac FIFO capture range. That more or less assumes streaming originates from a local server rather than a radio station. I am not aware of any system that currently implements something like that, but I don't rule out possibility something could be devised.
Regarding streaming audio from internet radio stations, presumably packets can be processed and buffered as needed so that a dac clock remains the primary time reference.
Regarding streaming audio from internet radio stations, presumably packets can be processed and buffered as needed so that a dac clock remains the primary time reference.
There is one DAC I read about that does not convert in real time, but uses some sort of a buffer, so the music keeps playing after the source is removed.
Does attempting to re-create the audio in real-time result in errors and distortion? Just wondering because I assume all modern equipment and source files are error - free due to error - correcting techniques. Network streaming can have errors, but a file off a hard disk or CD?
Does attempting to re-create the audio in real-time result in errors and distortion? Just wondering because I assume all modern equipment and source files are error - free due to error - correcting techniques. Network streaming can have errors, but a file off a hard disk or CD?
CD players have memories so the data can still be read at a constant rate when the speed of the drive fluctuates a bit. In the 1980's, those memories were usually DRAMs with a controller to make them behave as FIFOs, I don't know what is used nowadays.
I am not sure if Python has the functions I am looking for, but with the following code:
https://markhedleyjones.com/projects/python-tone-generator
generator = ToneGenerator()
generator.play(frequency, duration, amplitude)
If I could use a command to play the set of amplitudes one after another, with duration of 1/sampling rate, will it produce the required tone?
https://markhedleyjones.com/projects/python-tone-generator
generator = ToneGenerator()
generator.play(frequency, duration, amplitude)
If I could use a command to play the set of amplitudes one after another, with duration of 1/sampling rate, will it produce the required tone?
I would say, 'yes, if you mean in an absolute sense,' for each question above. However it really depends on how you want to define 'errors, noise, and distortion:' only bit-errors? only hissing noise and steady-state harmonic distortion? All possible kinds of error, noise, and distortion effects? Only those audible to everyone in the world with a 'normal' hearing test, audible to only to some smaller fraction of the population, easily measurable ones, mathematically predictable ones, something else?
Some people used to argue that digital audio is just ones and zeros so its impossible for playback from a hard disk to sound different from playback from a memory stick. Turns out they were wrong. The correct explanation was found only some time after a number of dac users reporting audible differences had been assured they were imagining something that was physically impossible. Turned out that some CD players are USB powered. Disk drive motors and memory sticks can affect power supply noise in computers differently. The noise can get into the USB power which can then affect dac sound quality. The effect was measured by one of the forum members here, KSTR. That said, if you were only asking about corrupt files in particular, most often they won't playback at all or will abruptly stop playing if disk drive data read errors occur. CD has different error handling so certain types of potentially audible data-read errors area possible if playing back from CD in real time.
Last edited: