Open flatmax opened 2 years ago
Hello. Resampling is not done in the chip. It is already done with an analog signal. The DAC operates at a floating frequency proportional to the playback speed. And after the DAC, an 8-order elliptical filter is installed. The filter is tuned to the Nyquist frequency. It tunes and changes its frequency in proportion to the change in playback speed.
Четверг, 16 декабря 2021, 4:54 +03:00 от Matt Flax @.***>: Hi there, I'm interested in how you did your resampling ? Did you resample on chip with interpolation or in some other way ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android .
Андрей Анацко Отправлено из Почты Mail.ru
Sounds good. Can I clarify your approach ? Are you changing the master clock of the DAC ? Then you are also changing the LPF filter's cut off frequency to match the sample rate ? I assume the sample rate is something like master clock frequency / 64 or / 128 or / 256 ?
Oh yes, also, can you tell me the latency of the system ? From moving the record to hearing the speed change on the speakers ? For things like serato I assume it has a large latency of say 20 ms. Also, can you scratch the record - i.e. you can use it for turntablism ?
I use a DAC with parallel data loading, its frequency changes smoothly, in small steps, in proportion to the change in the rotational speed of the plate. The LPF is also being reconfigures. I am generating these frequencies in the FPGA. This allows sounds above 22.050khz to be played when the record is spinning rapidly. And also reproduce ultra-low frequencies. This is very close to the sound of real vinyl. But to be honest. I chose this method due to lack of knowledge in dsp processes. So the method requires precise analog circuitry. In the next projects, I already use audio DACs with a constant master clock frequency, and I perform resampling in digital form, inside the ARM chips. The big advantage of this method is the very low latency. 1ms for digital part + signal passing through the analog part. I have not measured how long the delay takes for the analog part, but it is tens and hundreds of times less than 1ms. In addition, the manufacturers of audio cards always indicate the latency of the digital part only. I do not have an ADC, the timecode signal does not pass this conversion, there is no USB card, there is no delay in converting the interface, signal transmission via USB, as it is in audio cards. This is a very simple solution and very reliable at the same time.
Пятница, 24 декабря 2021, 9:05 +03:00 от Matt Flax @.***>: Oh yes, also, can you tell me the latency of the system ? From moving the record to hearing the speed change on the speakers ? For things like serato I assume it has a large latency of say 20 ms. Also, can you scratch the record - i.e. you can use it for turntablism ? — Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android . You are receiving this because you commented. Message ID: <djgreeb/Technics-DVS-Project/issues/1/1000672212 @ github . com>
Андрей Анацко Отправлено из Почты Mail.ru
Sounds fantastic I really like your work.
I have two projects running : RAM platter hybrid : https://github.com/Audio-Injector/RAMPlatterHybrid and RAM platter : https://github.com/flatmax/RAMPlatter . Both projects aim to give real vinyl feel to digital audio - particularly good for turning the turntable into a real instrument.
RAM platter hybrid aims to get as close to 1 ms latency as possible - however not sure that is possible on an ARM with DMA running Linux. RAM platter aims to get as close to 40 us as possible - it has to be implemented on something like an FPGA.
Both RAM platter approaches intend to use a varying master clock on the DAC to vary the sample rate - which I think is similar to your first approach, which in my opinion is the better approach. I am currently looking at different methods to turn a 1 kHz tone (from something like a Serato scratch record) into a suitable DAC master clock (0 to 50 MHz). Some advice from RF people using PLLs has been given - however I am also considering other approaches.
RAM platter hybrid runs on an ARM (in this case the Pi). The software loads all of the audio to memory (check the discussions) and pipes the audio from memory directly through DMA to the I2S bus. The problem with using ARM platforms and even other non-ARM microprocessors is that alsmost all of the use DMA and typically you can't get much below 1 ms for DMA. Further the audio subsystems are typically double buffered. It will be difficult to realise something with lower latency then 1 ms on an ARM core.
RAM platter is still in the thinking stage, however it can't use regular ARM cores nor microprocessors. The reason why these CPUs can't be used is that they typically all use DMA to interface the I2S bus. This DMA introduces too much latency.
I have shown previously and tested varying the DAC master clock - it works very well and takes a large amount of load off the CPUs. The general concept of frequency multiplying the time code signal from kHz to MHz solves any latency problems in working out time code from the record in software - the latency is only PLL jitter, which can be as low as 40 us.
It seems to me that it is not a good idea to use a 1kHz timecode signal for the master clock. You forget that the signal there is analog, from a vinyl record, which can also receive external interference in the form of vibrations. It will not be stable 1kHz. It will oscillate in amplitude and be modulated by noise. Because of this, the trigger will capture the period incorrectly. For example, 1 period is 993ms, the second is 1007ms. But in practice, the numbers will be worse. Jitter after PLL will reach 5-10%. And, as far as I know, PLL cannot start from one period, it will not start working after 1ms. Also, I'm not sure that there are PLLs that operate in such a wide range of frequencies. If you want to spin a record faster than the usual 4X or 8X playback speed, you need a PLL 0...8khz. If you want to achieve lower latency, use Traktor timecode, it has a carrier frequency of 2kHz
Суббота, 25 декабря 2021, 1:50 +03:00 от Matt Flax @.***>: Sounds fantastic I really like your work. I have two projects running : RAM platter hybrid : https://github.com/Audio-Injector/RAMPlatterHybrid and RAM platter : https://github.com/flatmax/RAMPlatter . Both projects aim to give real vinyl feel to digital audio - particularly good for turning the turntable into a real instrument. RAM platter hybrid aims to get as close to 1 ms latency as possible - however not sure that is possible on an ARM with DMA running Linux. RAM platter aims to get as close to 40 us as possible - it has to be implemented on something like an FPGA. Both RAM platter approaches intend to use a varying master clock on the DAC to vary the sample rate - which I think is similar to your first approach, which in my opinion is the better approach. I am currently looking at different methods to turn a 1 kHz tone (from something like a Serato scratch record) into a suitable DAC master clock (0 to 50 MHz). Some advice from RF people using PLLs has been given - however I am also considering other approaches. RAM platter hybrid runs on an ARM (in this case the Pi). The software loads all of the audio to memory (check the discussions) and pipes the audio from memory directly through DMA to the I2S bus. The problem with using ARM platforms and even other non-ARM microprocessors is that alsmost all of the use DMA and typically you can't get much below 1 ms for DMA. Further the audio subsystems are typically double buffered. It will be difficult to realise something with lower latency then 1 ms on an ARM core. RAM platter is still in the thinking stage, however it can't use regular ARM cores nor microprocessors. The reason why these CPUs can't be used is that they typically all use DMA to interface the I2S bus. This DMA introduces too much latency. I have shown previously and tested varying the DAC master clock - it works very well and takes a large amount of load off the CPUs. The general concept of frequency multiplying the time code signal from kHz to MHz solves any latency problems in working out time code from the record in software - the latency is only PLL jitter, which can be as low as 40 us. — Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android . You are receiving this because you commented. Message ID: <djgreeb/Technics-DVS-Project/issues/1/1000943143 @ github . com>
Андрей Анацко Отправлено из Почты Mail.ru
True, there will be jitter, but there always is jitter. When starting from a stop, the samples and sample rate is so slow, I don't actually think jitter is an issue at these low frequencies. This needs to be investigated further.
Once the system is locked I would expect PLL jitter to be much more managable.
On the topic of the PLL architecture - actually we seem to need two PLLs cascaded to manage the jitter and frequency range. Here is one really nice suggestion from a Texas Instruments RF engineer. The basic idea is to frequency shift the base band (using a mixer) up to 10 MHz, then to use a first PLL to frequency expand the signal by 100 times. The same process is taken again to frequency expand the signal by 120 times. We end up with a frequency expansion of 12000 times. This turns the 1 kHz tone into a 12 MHz tone.
Hi there,
I'm interested in how you did your resampling ? Did you resample on chip with interpolation or in some other way ?