I know that linux driver has sample rate fixed at 39063 Hz by design, but I want to ask is it possible to have it working at other rates (e.g. 44100 Hz). I managed to get playback resampled by ALSA, but it's not enough, because I want to use my POD XT with JACK and Ardour and this kind software requires 'hw', and won't work with 'plug' devices.
One may ask why not working with the lower rate - I would like to record my guitars with POD, but I think my laptop built in soundcard is just enough for creating drum and other virtual instrument tracks, and apparently most soundcarts don't support 39063 Hz samplerate so I cannot open my POD sessions in Ardour using onboard soundcard. And manually resampling each track really misses the point of multitrack recording.
I don't know how it's possible, but Windows driver can work with 44.1k and 48k rates - does it mean that audio is resampled by the driver? Or could it be that the driver reports such rates, but it's a fake (since 39062.5 Hz is the internal sampling according to your documentation) and nobody notices the difference, because it's not audible?
Anyway, right now I have no required knowledge and skill to implement anything myself (either software resampling or 'fake' sample rate), and I am really afraid of breaking something, so before I start, could you please tell me is it possible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 39062.5 Hz rate is fixed by the A/D converter in the device, which is synchronized with the USB bus clock. So there is no real solution, only a few workarounds, but probably not exactly what you are looking for:
*) You mentioned plughw, but as you noted it can't be used with jack. Moreover, this does simple linear interpolation, and the signal quality probably suffers from a 39->44->39 kHz roundtrip.
*) The POD Xt can do its own resampling, but only for the digital audio connectors (not for USB). Unless your laptop has a digital audio interface, this won't help you either.
*) However, nothing (except lack of time) prevents one from implementing a sophisticated resampler inside the driver (Line6 did that for their Windows driver). It's not a very clean solution since it somewhat duplicates what ALSA does, but probably closest to your requirements. I think if you look up the correct formulas, it shouldn't be too hard, and the risk of breaking anything is quite low (in the worst case your machine could crash). If you want to give it a try, I can provide some hints regarding the driver code.
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It made my day :) Now everything is being resampled by ALSA (even though it is linear it's enough for my homerecording) and I can run jack with 44100 Hz on hw:1. I don't know how this change affects other parts of a driver. Would you consider changing these values in the main source tree if it doesn't break anything?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well my enthusiasm was premature. Audio is not being resampled, but played slower. The good thing is that it works the other way round - I can run jack on my onboard soundcard with 39063. It surprised me, because I thought it was impossible :) I treat it as a temporary workaround, and I started thinking about this driver-inside resampler. Please post any hints regarding that subject since i am a complete noob in programming kernel drivers and audio applications :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Audio is not being resampled, but played slower.
I would have been very surprised if it were as easy as that, at least I didn't implement anything to take into account the sample rate requested by the application :-)
> Please post any hints regarding that subject
A resampler would best fit at the place where audio data are copied between application and driver memory (look for "memcpy" in "playback.c" and "capture.c"). Then there are at least two tricky issues:
*) find a proper filter (tradeoff between performance and complexity)
*) deal with "fractional" samples due to the non-integer frequency quotient (44100 / 39062.5)
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would strongly prefer to use some existing stuff instead of reinventing the wheel. If you can manage to use the libsamplerate plugin together with ardour, your problem is solved. Please let us know what you find out!
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have worked hard on this issue, but still no success. Trying various tricks with .asoundrc I ended up with that.
pcm.podxt {
type hw
card Line6USB
}
pcm.resampler {
type rate
slave {
pcm podxt
format S24_3LE
rate 39063
}
converter "samplerate"
}
ctl.resampler {
type hw
card Line6USB
}
pcm.!default {
type plug
slave.pcm resampler
}
Now I am able to play audio at any rate using ALSA-compatible players (aplay, mplayer) and record my guitar at 44.1k with arecord. But it still doesn't work with jack/ardour at 44100 - FAIL.
I have tried embedding a software resampler in the driver as well. I thought the easiest way would be to use an existing one, so I've decided to try with libsamplerate. First problem: I can't link with external libraries, even with EXTRA_LDFLAGS += -L/usr/lib --start-group -lsamplerate --end-group which should work according to the ld manual. It will link if i do it manually by doing KBUILD_VERBOSE=1 make then copying the ld command, pasting it with -L/usr/lib -lsamplerate appended at the end and typing make again. But my custom driver has failed anyway - it has made my system unresponsive leaving it with Caps Lock indicator blinking. And I don't know how to debug it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> But it still doesn't work with jack/ardour at 44100 - FAIL.
jack insists on a power-of-two period size, and ALSA insists on (almost) integer period sizes, which restricts the available sampling rates. I just tried with 39063 * 512 / 417 = 47962.2, configured jack to run at 47961 Hz, and jack nicely started and played (at a higher pitch of course) an ardour session that was previously recorded at 39063 Hz. But currently I don't see any way to simultaneously use period size 512 and sampling rate 48 kHz.
I'm not yet sure which part of ALSA is responsible for this behaviour, I'll have to dig a bit more through the source code to figure it out. If it can be fixed in the resampler plugin, it's probably not too hard to do since this is just a small wrapper layer around the samplerate library. Anyway the plugin needs to be improved to be useful for PODxt users since it only operates at 16 bit.
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I know that linux driver has sample rate fixed at 39063 Hz by design, but I want to ask is it possible to have it working at other rates (e.g. 44100 Hz). I managed to get playback resampled by ALSA, but it's not enough, because I want to use my POD XT with JACK and Ardour and this kind software requires 'hw', and won't work with 'plug' devices.
One may ask why not working with the lower rate - I would like to record my guitars with POD, but I think my laptop built in soundcard is just enough for creating drum and other virtual instrument tracks, and apparently most soundcarts don't support 39063 Hz samplerate so I cannot open my POD sessions in Ardour using onboard soundcard. And manually resampling each track really misses the point of multitrack recording.
I don't know how it's possible, but Windows driver can work with 44.1k and 48k rates - does it mean that audio is resampled by the driver? Or could it be that the driver reports such rates, but it's a fake (since 39062.5 Hz is the internal sampling according to your documentation) and nobody notices the difference, because it's not audible?
Anyway, right now I have no required knowledge and skill to implement anything myself (either software resampling or 'fake' sample rate), and I am really afraid of breaking something, so before I start, could you please tell me is it possible?
The 39062.5 Hz rate is fixed by the A/D converter in the device, which is synchronized with the USB bus clock. So there is no real solution, only a few workarounds, but probably not exactly what you are looking for:
*) You mentioned plughw, but as you noted it can't be used with jack. Moreover, this does simple linear interpolation, and the signal quality probably suffers from a 39->44->39 kHz roundtrip.
*) The POD Xt can do its own resampling, but only for the digital audio connectors (not for USB). Unless your laptop has a digital audio interface, this won't help you either.
*) However, nothing (except lack of time) prevents one from implementing a sophisticated resampler inside the driver (Line6 did that for their Windows driver). It's not a very clean solution since it somewhat duplicates what ALSA does, but probably closest to your requirements. I think if you look up the correct formulas, it shouldn't be too hard, and the risk of breaking anything is quite low (in the worst case your machine could crash). If you want to give it a try, I can provide some hints regarding the driver code.
Kind regards,
Markus
One more thing (I should have read this before): have a look at "http://www.ardour.org/node/1280"
Kind regards,
Markus
Or I should have encouraged myself to play a bit with the source code earlier :P
--- line6usb-0.7.3/playback.c 2008-01-19 02:46:01.000000000 +0100
+++ line6usb-0.7.3-dev/playback.c 2008-10-08 15:09:46.000000000 +0200
@@ -33,7 +33,7 @@
.formats = SNDRV_PCM_FMTBIT_S24_3LE,
.rates = SNDRV_PCM_RATE_KNOT,
.rate_min = 39063,
- .rate_max = 39063,
+ .rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.buffer_bytes_max = 60000,
--- line6usb-0.7.3/capture.c 2008-01-19 02:46:01.000000000 +0100
+++ line6usb-0.7.3-dev/capture.c 2008-10-08 15:09:56.000000000 +0200
@@ -32,7 +32,7 @@
.formats = SNDRV_PCM_FMTBIT_S24_3LE,
.rates = SNDRV_PCM_RATE_KNOT,
.rate_min = 39063,
- .rate_max = 39063,
+ .rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.buffer_bytes_max = 60000,
It made my day :) Now everything is being resampled by ALSA (even though it is linear it's enough for my homerecording) and I can run jack with 44100 Hz on hw:1. I don't know how this change affects other parts of a driver. Would you consider changing these values in the main source tree if it doesn't break anything?
Well my enthusiasm was premature. Audio is not being resampled, but played slower. The good thing is that it works the other way round - I can run jack on my onboard soundcard with 39063. It surprised me, because I thought it was impossible :) I treat it as a temporary workaround, and I started thinking about this driver-inside resampler. Please post any hints regarding that subject since i am a complete noob in programming kernel drivers and audio applications :)
> Audio is not being resampled, but played slower.
I would have been very surprised if it were as easy as that, at least I didn't implement anything to take into account the sample rate requested by the application :-)
> Please post any hints regarding that subject
A resampler would best fit at the place where audio data are copied between application and driver memory (look for "memcpy" in "playback.c" and "capture.c"). Then there are at least two tricky issues:
*) find a proper filter (tradeoff between performance and complexity)
*) deal with "fractional" samples due to the non-integer frequency quotient (44100 / 39062.5)
Kind regards,
Markus
Just found this one:
https://bugs.launchpad.net/ubuntu/+source/alsa-plugins/+bug/57089
I would strongly prefer to use some existing stuff instead of reinventing the wheel. If you can manage to use the libsamplerate plugin together with ardour, your problem is solved. Please let us know what you find out!
Kind regards,
Markus
I have worked hard on this issue, but still no success. Trying various tricks with .asoundrc I ended up with that.
pcm.podxt {
type hw
card Line6USB
}
pcm.resampler {
type rate
slave {
pcm podxt
format S24_3LE
rate 39063
}
converter "samplerate"
}
ctl.resampler {
type hw
card Line6USB
}
pcm.!default {
type plug
slave.pcm resampler
}
Now I am able to play audio at any rate using ALSA-compatible players (aplay, mplayer) and record my guitar at 44.1k with arecord. But it still doesn't work with jack/ardour at 44100 - FAIL.
I have tried embedding a software resampler in the driver as well. I thought the easiest way would be to use an existing one, so I've decided to try with libsamplerate. First problem: I can't link with external libraries, even with EXTRA_LDFLAGS += -L/usr/lib --start-group -lsamplerate --end-group which should work according to the ld manual. It will link if i do it manually by doing KBUILD_VERBOSE=1 make then copying the ld command, pasting it with -L/usr/lib -lsamplerate appended at the end and typing make again. But my custom driver has failed anyway - it has made my system unresponsive leaving it with Caps Lock indicator blinking. And I don't know how to debug it.
> But it still doesn't work with jack/ardour at 44100 - FAIL.
jack insists on a power-of-two period size, and ALSA insists on (almost) integer period sizes, which restricts the available sampling rates. I just tried with 39063 * 512 / 417 = 47962.2, configured jack to run at 47961 Hz, and jack nicely started and played (at a higher pitch of course) an ardour session that was previously recorded at 39063 Hz. But currently I don't see any way to simultaneously use period size 512 and sampling rate 48 kHz.
I'm not yet sure which part of ALSA is responsible for this behaviour, I'll have to dig a bit more through the source code to figure it out. If it can be fixed in the resampler plugin, it's probably not too hard to do since this is just a small wrapper layer around the samplerate library. Anyway the plugin needs to be improved to be useful for PODxt users since it only operates at 16 bit.
Kind regards,
Markus
> Anyway the plugin needs to be improved to be useful for PODxt users since it only operates at 16 bit.
I haven't seen the source yet, but it should not be so hard, since libsamplerate operates on 32 bit float