@Soren
It would be nice to have a "status" command in playing mode, which displays all relevant actual settings on request: I would suggest to display at least sample rate, volume, selected FIR1, selected FIR2. I is a bit of work to have to switch to management mode and back to check the filters,
Moreover as option, choosable in management mode, it would be nice to call status automatically after any change in play mode.
It would be nice to have a "status" command in playing mode, which displays all relevant actual settings on request: I would suggest to display at least sample rate, volume, selected FIR1, selected FIR2. I is a bit of work to have to switch to management mode and back to check the filters,
Moreover as option, choosable in management mode, it would be nice to call status automatically after any change in play mode.
I confirm that the sample rate locking pops are gone for me as well. Dam1021 can now be now be used directly with a power amp, without an attenuator in between 🙂. Thank you Soeren!
There are still power on/off plops, but those can be handled by an external muting circuit.
I agree with zfe, the ability to query current state over serial line is a badly needed feature for anyone wishing to use a microcontroller. I suggest to make it simple and print the current value of a setting when a command is entered without a parameter. For example 'I' would print the currently selected input, 'V' - current volume and so on.
Having each setting available separately , as opposed to a full status report with all settings, would be more in line with how dam1021 already reports status changes. Both push and pull status updates can then be handled by the same code on the controller.
There are still power on/off plops, but those can be handled by an external muting circuit.
I agree with zfe, the ability to query current state over serial line is a badly needed feature for anyone wishing to use a microcontroller. I suggest to make it simple and print the current value of a setting when a command is entered without a parameter. For example 'I' would print the currently selected input, 'V' - current volume and so on.
Having each setting available separately , as opposed to a full status report with all settings, would be more in line with how dam1021 already reports status changes. Both push and pull status updates can then be handled by the same code on the controller.
Mine is without clicks as well. I have JLsounds USB interface btw. Thanks.
I don't know which end to blame ,but Dam still loses clock during some silent passages, instead of 'click' i get silent parts.
I don't know which end to blame ,but Dam still loses clock during some silent passages, instead of 'click' i get silent parts.
I agree with zfe, the ability to query current state over serial line is a badly needed feature for anyone wishing to use a microcontroller. I suggest to make it simple and print the current value of a setting when a command is entered without a parameter. For example 'I' would print the currently selected input, 'V' - current volume and so on.
I have no major objection, but with "F" things get complicated.
An answer just mirroring the input, so e.g. "F4" is not what I want to know.
Preferably I would like to see the full information you get with "filters".
At lest the "numbers" of all FIR and IIR filters currently loaded.
For all recordings I tested up to now (new, high sample rate recordings) the deemphasis IIR filter is loaded (according to "filters" in management mode). I would only have expected old CD recordings from the 80-ies to have pre-emphasis.
So: could please the correct behavior of activating the deemphasis filter respectively the reporting of "filters" be checked.
So: could please the correct behavior of activating the deemphasis filter respectively the reporting of "filters" be checked.
For all recordings I tested up to now (new, high sample rate recordings) the deemphasis IIR filter is loaded (according to "filters" in management mode). I would only have expected old CD recordings from the 80-ies to have pre-emphasis.
So: could please the correct behavior of activating the deemphasis filter respectively the reporting of "filters" be checked.
Yes, de-emphasis filters are always loaded, but only enabled when emphasis bit is set in spdif datastream.
If loaded and active are different things, the information if a loaded filter is active would also be of importance and should be indicated somehow.Yes, de-emphasis filters are always loaded, but only enabled when emphasis bit is set in spdif datastream.
Just a small request... Is it possible to add a reset command? I actually don't like having to power cycle that often because of all the related stresses. Right now I'm getting around this by "updating umanager" that resets the fpga. But this should be simpler?
Working without pops etc on an RPi 2 via I2s into the DAM. Using Voyage MPD 0.9. Sample rate changes are flawless under normal, continuous play. What a difference that makes - thanks Soren!
Only non-positive observation is that if you manually change to a track with a different sample rate (as against the song ending and changing track on its own) there is a SLIGHT glitch. Nothing near the previous issue.
The isolated serial port works well with an Uno (clone), OLED display and Apple remote - using a cobbled together combination of glt and Dimdim's efforts. Next step is to add remote switching of the filters to the code.
Now to load Paul's grab bag...
Only non-positive observation is that if you manually change to a track with a different sample rate (as against the song ending and changing track on its own) there is a SLIGHT glitch. Nothing near the previous issue.
The isolated serial port works well with an Uno (clone), OLED display and Apple remote - using a cobbled together combination of glt and Dimdim's efforts. Next step is to add remote switching of the filters to the code.
Now to load Paul's grab bag...
@Soekris
Can you confirm whether the new production run dam1021 expected this month will have the same physical dimensions and connector layout as earlier revisions?
Can you confirm whether the new production run dam1021 expected this month will have the same physical dimensions and connector layout as earlier revisions?
I've updated the python dam1021 library to handle new features of 0.99 firmware pack. Pretty everything that you can do directly can also be done using this library. The library handles Søren filter set name convention as well as Paul's one. So you can select filter set this way:
$ python /path/to/dam1021.py -f minimum
Or this way:
$ python /path/to/dam1021.py -f 3
Current filter set is presented as follows ('-' marks indentation):
$ python /path/to/dam1021.py -c
INFO:dam1021:
FIR filters:
--Bank 03:
----FIR1: type(06) Low_Delay_v4, 44.1 Khz, 0-17.00Khz +-0.00000909dB, 28.00Khz -120.83dB
----FIR2: type(10) Low_Delay_v4, 352.8 Khz, 0-20.00Khz +-0.00000893dB, 282.24Khz -120.98dB
IIR filters:
--type(29) DC Blocking IIR, 352.8 Ksps, 2 Hz HP 1st order
--type(30) Deemphasis IIR, 352.8 Ksps, 50/15 uS
Also all available filters are dived into corresponding groups:
$ python /path/to/dam1021.py -a
INFO:dam1021:
FIR filters:
--Bank 01:
----FIR1: type(04) EQHQv5, 44.1 Khz, 0-20.70Khz +-0.00000029dB, 22.50Khz -164.18dB
----FIR1: type(04) EQHQv5, 48.0 Khz, 0-21.50Khz +-0.00000030dB, 24.00Khz -164.05dB
----FIR1: type(04) EQHQv5, 88.2 Khz, 0-26.00Khz +-0.00000029dB, 35.28Khz -164.33dB
----FIR1: type(04) EQHQv5, 96.0 Khz, 0-26.00Khz +-0.00000026dB, 38.40Khz -165.16dB
----FIR1: type(04) EQHQv5, 176.4 Khz, 0-30.00Khz +-0.00000020dB, 70.56Khz -167.36dB
----FIR1: type(04) EQHQv5, 192.0 Khz, 0-30.00Khz +-0.00000025dB, 76.80Khz -165.70dB
----FIR1: type(04) Bypass FIR1, 352.8 Ksps
----FIR1: type(04) Bypass FIR1, 384 Ksps
----FIR2: type(08) EQHQv5, 352.8 Khz, 0-30.00Khz +-0.00000006dB, 282.24Khz -177.14dB
----FIR2: type(08) EQHQv5, 384.0 Khz, 0-30.00Khz +-0.00000029dB, 307.20Khz -164.19dB
--Bank 02:
----FIR1: type(05) EQHQ_Apo, 44.1 Khz, 0-20.23Khz +-0.00000029dB, 22.05Khz -164.21dB
----FIR1: type(05) EQHQ_Apo, 48.0 Khz, 0-20.23Khz +-0.00000029dB, 23.90Khz -164.32dB
----FIR1: type(05) EQHQ_Apo, 88.2 Khz, 0-20.23Khz +-0.00000022dB, 39.69Khz -166.50dB
----FIR1: type(05) EQHQ_Apo, 96.0 Khz, 0-20.23Khz +-0.00000029dB, 43.20Khz -164.32dB
----FIR1: type(05) EQHQ_Apo, 176.4 Khz, 0-20.23Khz +-0.00000025dB, 79.38Khz -165.72dB
----FIR1: type(05) EQHQ_Apo, 192.0 Khz, 0-20.23Khz +-0.00000019dB, 86.40Khz -168.00dB
----FIR2: type(09) EQHQ_Apo, 352.8 Khz, 0-20.22Khz +-0.00000027dB, 273.42Khz -164.79dB
----FIR2: type(09) EQHQ_Apo, 384.0 Khz, 0-20.22Khz +-0.00000012dB, 297.60Khz -171.80dB
--Bank 03:
----FIR1: type(06) Low_Delay_v4, 44.1 Khz, 0-17.00Khz +-0.00000909dB, 28.00Khz -120.83dB
----FIR1: type(06) Low_Delay_v4, 48.0 Khz, 0-18.50Khz +-0.00000892dB, 30.00Khz -120.99dB
----FIR1: type(06) Low_Delay_v4, 88.2 Khz, 0-20.00Khz +-0.00000909dB, 35.28Khz -120.83dB
----FIR1: type(06) Low_Delay_v4, 96.0 Khz, 0-20.00Khz +-0.00000960dB, 38.40Khz -120.35dB
----FIR1: type(06) Low_Delay_v4, 176.4 Khz, 0-20.00Khz +-0.00000949dB, 70.56Khz -120.46dB
----FIR1: type(06) Low_Delay_v4, 192.0 Khz, 0-20.00Khz +-0.00000944dB, 76.80Khz -120.50dB
----FIR2: type(10) Low_Delay_v4, 352.8 Khz, 0-20.00Khz +-0.00000893dB, 282.24Khz -120.98dB
----FIR2: type(10) Low_Delay_v4, 384.0 Khz, 0-20.00Khz +-0.00000803dB, 313.44Khz -121.91dB
--Bank 04:
----FIR1: type(07) NewNOS, 44.1Khz Samplerate
----FIR1: type(07) NewNOS, 48Khz Samplerate
----FIR1: type(07) NewNOS, 88.2 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 96 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 176.4 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 192 Khz Samplerate, Bypass
----FIR2: type(11) NewNOS, 352 Khz Samplerate Bypass
----FIR2: type(11) NewNOS, 384 Khz Samplerate Bypass
IIR filters:
--type(29) DC Blocking IIR, 352.8 Ksps, 2 Hz HP 1st order
--type(29) DC Blocking IIR, 384 Ksps, 2 Hz HP 1st order
--type(30) Deemphasis IIR, 352.8 Ksps, 50/15 uS
--type(30) Deemphasis IIR, 384 Ksps, 50/15 uS
Anyway you may adjust this to your liking by processing return values of the corresponding API calls.
This release also comes with the default settings adjusted for RPi users. Combine that Mopidy [2] and mopidy-dam1021 [3] extension and you've got a comprehensive end-to-end solution tailored to this DAC.
More info available at [1].
[1] https://github.com/fortaa/dam1021
[2] https://www.mopidy.com/
[3] https://github.com/fortaa/mopidy-dam1021
$ python /path/to/dam1021.py -f minimum
Or this way:
$ python /path/to/dam1021.py -f 3
Current filter set is presented as follows ('-' marks indentation):
$ python /path/to/dam1021.py -c
INFO:dam1021:
FIR filters:
--Bank 03:
----FIR1: type(06) Low_Delay_v4, 44.1 Khz, 0-17.00Khz +-0.00000909dB, 28.00Khz -120.83dB
----FIR2: type(10) Low_Delay_v4, 352.8 Khz, 0-20.00Khz +-0.00000893dB, 282.24Khz -120.98dB
IIR filters:
--type(29) DC Blocking IIR, 352.8 Ksps, 2 Hz HP 1st order
--type(30) Deemphasis IIR, 352.8 Ksps, 50/15 uS
Also all available filters are dived into corresponding groups:
$ python /path/to/dam1021.py -a
INFO:dam1021:
FIR filters:
--Bank 01:
----FIR1: type(04) EQHQv5, 44.1 Khz, 0-20.70Khz +-0.00000029dB, 22.50Khz -164.18dB
----FIR1: type(04) EQHQv5, 48.0 Khz, 0-21.50Khz +-0.00000030dB, 24.00Khz -164.05dB
----FIR1: type(04) EQHQv5, 88.2 Khz, 0-26.00Khz +-0.00000029dB, 35.28Khz -164.33dB
----FIR1: type(04) EQHQv5, 96.0 Khz, 0-26.00Khz +-0.00000026dB, 38.40Khz -165.16dB
----FIR1: type(04) EQHQv5, 176.4 Khz, 0-30.00Khz +-0.00000020dB, 70.56Khz -167.36dB
----FIR1: type(04) EQHQv5, 192.0 Khz, 0-30.00Khz +-0.00000025dB, 76.80Khz -165.70dB
----FIR1: type(04) Bypass FIR1, 352.8 Ksps
----FIR1: type(04) Bypass FIR1, 384 Ksps
----FIR2: type(08) EQHQv5, 352.8 Khz, 0-30.00Khz +-0.00000006dB, 282.24Khz -177.14dB
----FIR2: type(08) EQHQv5, 384.0 Khz, 0-30.00Khz +-0.00000029dB, 307.20Khz -164.19dB
--Bank 02:
----FIR1: type(05) EQHQ_Apo, 44.1 Khz, 0-20.23Khz +-0.00000029dB, 22.05Khz -164.21dB
----FIR1: type(05) EQHQ_Apo, 48.0 Khz, 0-20.23Khz +-0.00000029dB, 23.90Khz -164.32dB
----FIR1: type(05) EQHQ_Apo, 88.2 Khz, 0-20.23Khz +-0.00000022dB, 39.69Khz -166.50dB
----FIR1: type(05) EQHQ_Apo, 96.0 Khz, 0-20.23Khz +-0.00000029dB, 43.20Khz -164.32dB
----FIR1: type(05) EQHQ_Apo, 176.4 Khz, 0-20.23Khz +-0.00000025dB, 79.38Khz -165.72dB
----FIR1: type(05) EQHQ_Apo, 192.0 Khz, 0-20.23Khz +-0.00000019dB, 86.40Khz -168.00dB
----FIR2: type(09) EQHQ_Apo, 352.8 Khz, 0-20.22Khz +-0.00000027dB, 273.42Khz -164.79dB
----FIR2: type(09) EQHQ_Apo, 384.0 Khz, 0-20.22Khz +-0.00000012dB, 297.60Khz -171.80dB
--Bank 03:
----FIR1: type(06) Low_Delay_v4, 44.1 Khz, 0-17.00Khz +-0.00000909dB, 28.00Khz -120.83dB
----FIR1: type(06) Low_Delay_v4, 48.0 Khz, 0-18.50Khz +-0.00000892dB, 30.00Khz -120.99dB
----FIR1: type(06) Low_Delay_v4, 88.2 Khz, 0-20.00Khz +-0.00000909dB, 35.28Khz -120.83dB
----FIR1: type(06) Low_Delay_v4, 96.0 Khz, 0-20.00Khz +-0.00000960dB, 38.40Khz -120.35dB
----FIR1: type(06) Low_Delay_v4, 176.4 Khz, 0-20.00Khz +-0.00000949dB, 70.56Khz -120.46dB
----FIR1: type(06) Low_Delay_v4, 192.0 Khz, 0-20.00Khz +-0.00000944dB, 76.80Khz -120.50dB
----FIR2: type(10) Low_Delay_v4, 352.8 Khz, 0-20.00Khz +-0.00000893dB, 282.24Khz -120.98dB
----FIR2: type(10) Low_Delay_v4, 384.0 Khz, 0-20.00Khz +-0.00000803dB, 313.44Khz -121.91dB
--Bank 04:
----FIR1: type(07) NewNOS, 44.1Khz Samplerate
----FIR1: type(07) NewNOS, 48Khz Samplerate
----FIR1: type(07) NewNOS, 88.2 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 96 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 176.4 Khz Samplerate, Bypass
----FIR1: type(07) NewNOS, 192 Khz Samplerate, Bypass
----FIR2: type(11) NewNOS, 352 Khz Samplerate Bypass
----FIR2: type(11) NewNOS, 384 Khz Samplerate Bypass
IIR filters:
--type(29) DC Blocking IIR, 352.8 Ksps, 2 Hz HP 1st order
--type(29) DC Blocking IIR, 384 Ksps, 2 Hz HP 1st order
--type(30) Deemphasis IIR, 352.8 Ksps, 50/15 uS
--type(30) Deemphasis IIR, 384 Ksps, 50/15 uS
Anyway you may adjust this to your liking by processing return values of the corresponding API calls.
This release also comes with the default settings adjusted for RPi users. Combine that Mopidy [2] and mopidy-dam1021 [3] extension and you've got a comprehensive end-to-end solution tailored to this DAC.
More info available at [1].
[1] https://github.com/fortaa/dam1021
[2] https://www.mopidy.com/
[3] https://github.com/fortaa/mopidy-dam1021
Speaking about communication with the outside world, what I miss the most is retrieval of the current volume level which is crucial for reliant volume control. This might be complicated at least or PITA in practice when you've got several clients talking to the board. And the 'filters' command should have returned only active filters (deemphasis case).
Everything else could be retrieved right now. And basically the discussion boils down to personal preferences and conventions IMO.
Everything else could be retrieved right now. And basically the discussion boils down to personal preferences and conventions IMO.
Last edited:
Just a small request... Is it possible to add a reset command? I actually don't like having to power cycle that often because of all the related stresses. Right now I'm getting around this by "updating umanager" that resets the fpga. But this should be simpler?
The "update" command should only be used when loading new firmware, it erase and rewrite the uC internal flash which is a high risk process that if goes wrong require hardware to fix....
I'll look into adding a reset command, but it's not that simple as to really work the fpga code also need to be reloaded....
@Soekris
Can you confirm whether the new production run dam1021 expected this month will have the same physical dimensions and connector layout as earlier revisions?
Next batch will be the same physically.
Again I'm just waiting for the f****** last precision resistors to be able to mount the boards....
The "update" command should only be used when loading new firmware, it erase and rewrite the uC internal flash which is a high risk process that if goes wrong require hardware to fix....
I'll look into adding a reset command, but it's not that simple as to really work the fpga code also need to be reloaded....
Thanks for this Soren! I found out about it when messing around with the ST-Link hardware. But yes, if you can add a reset command it'd be perfect.
Next batch will be the same physically.
Again I'm just waiting for the f****** last precision resistors to be able to mount the boards....
Soren,
Will the next batch include the resistor and cap fixes ?
http://www.diyaudio.com/forums/vend...magnitude-24-bit-384-khz-311.html#post4392832
Soren,
Will the next batch include the resistor and cap fixes ?
http://www.diyaudio.com/forums/vend...magnitude-24-bit-384-khz-311.html#post4392832
yes Im also expecting the new one will be with the resistor and cap fixes.
Hi Soren Im thinking to add the B1 buffer circuit with LSK489 where the power is directly taken from the +12 and -12 Analog rails will that bear that load without issues?
yes Im also expecting the new one will be with the resistor and cap fixes.
I'm also waiting for the new batch. The software update seems to solve quite a lot of issues, but these errors can only be repaired with hardware mods.
Is there any other known issue should be hardware fixed?
Next batch will be the same physically.
Again I'm just waiting for the f****** last precision resistors to be able to mount the boards....
Are there any other changes to the board than the vRef?
//
- Home
- Vendor's Bazaar
- Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 KHz