H9000 Sample Rate Conversion

[macgee]

Hi there

I know the H9000 doesn’t do Sample Rate Conversion today however is there a view to do this in future?

For 2 and a half reasons

1) My audio sessions are 96k and many H9000 algorithms don’t work at 96k – so if H9000 could receive 96k from external sources and downconvert to 48k for processing internally and then outputs 96k.

2) For audio devices that don’t function above 48k, it would be useful if digital signals could be recieved at 48k and up converted to 96k prior to processing

3) As a general utility

Regarding 48k only Alogs, as you know not all algorithms on H9000 support 96k, will support for 96k be added or at least support up sampling of those algorithms to 96K?

Thanks

[jbamberg]

macgee wrote:

Hi there

I know the H9000 doesn't do Sample Rate Conversion today however is there a view to do this in future?

For 2 and a half reasons

1) My audio sessions are 96k and many H9000 algorithms don't work at 96k – so if H9000 could receive 96k from external sources and downconvert to 48k for processing internally and then outputs 96k.

2) For audio devices that don't function above 48k, it would be useful if digital signals could be recieved at 48k and up converted to 96k prior to processing

3) As a general utility

Regarding 48k only Alogs, as you know not all algorithms on H9000 support 96k, will support for 96k be added or at least support up sampling of those algorithms to 96K?

Thanks

We've had a previous request for the ability to downconvert internally (within the DSPs) so that you could use the H9000 in a 96k session even if some of the loaded algorithms didn't support 96k processing.  This is a good idea and it's helpful to hear another request for this.  We're likely to add this in a software update.

Going the other way (your item 2) is maybe less important?  For algorithms where higher sample rate processing is necessary for them to sound good (e.g. our distortion algorithms), we already do upsampling internally in those algorithms.

3) is very difficult, since all the digital audio paths in the H9000 routing fabric currently run at the same rate – you couldn't, for example, take a USB audio signal at 96k and output AES/EBU at 48k.  Changing this would be a large undertaking and we'd probably opt to spend that time making new algorithms instead.

 

[macgee]

Thanks for that.
1) Great to hear, this would be very welcomed

2) I was actually referring to an external audio device like Lexicon MX400XL for example. So if H9000 was running at 96k, and Lexicon was feeding spdif input on Eventide at 48k then the system having the ability to deal with that without clocking issues. But by the sounds of your response to point 3, I’m guessing not?

3) Understood

[Author]

Posts