Jim and Ramesh (chan_voter and RPi)
Hi all, I was thinking, even though the RaspberryPi can't handle the audio stream from a URI due to the limitations of the USB bus, what is the ethernet performance like? I imagine it wouldn't be terribly good, due to the fact the ethernet swings off the USB, but hear me out... chan_voter is a module that communicates via ethernet, am I correct? It uses an RTCM connected over an ethernet bus to communicate the voice data around, and I can imagine, at a low codec rate like GSM or even Speex, throughput wouldn't be as excessive as raw sound data coming from a fob. So my proposal is, before Jim and Ramesh throw out the baby with the bathwater, and consign the RPi effort to the dust, why not take the work, which I believe involves getting Zaptel/ DAHDI to work with the RPi, and apply it to a purely chan_voter system? Yes, I know the chan_voter is dependant upon app_rpt, and in the future, someone, somewhere, is going to try to hook up a sound fob, and miserably complain it doesn't work, but we get the same questions about Asterisk 1.8 over and over too, right? The advantages here are manyfold - again, low power consumption comes into the game, everyone knows I personally need as low a power consumption as I can get. The fact the RTCM data (ie, VoIP over ethernet) is much more suited to the infrastructure on the RPi is a good thing here too. The fact that normal Asterisk just runs, and runs well, on RPi is another motivating factor - my friend Andrew is running his house PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. And yes, simply the cool factor - who else can say they run their voting repeater system off something the size of a credit card, with all the proprietary, messy, rack mounted stuff out there? If Jim and Ramesh are unwilling, or unable, to help, due to the fact that the RPi is a bit of a letdown (I heard about the USB performance issues - ouch!), I would like to take their work, and apply it to a platform I think may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 I/Os? For $49, gets you something good, look it up, www.cubieboard.org - I got one for Christmas, and I thought it would be good for this. Its a Chinese Allwinnner A10 device. Since I have gone beyond just simple URI systems since Jim introduced me to the RTCM, I would like to get this to work. I recognised the RTCM did something I was talking to Andrew about on the way home from Expedition in October of this year - "Wouldn't it be nice, Andrew, if we could have a voting system that allows us the flexibility to run an Expeditions communications in such a way that make it simply easy for us, and easy for the users?" Before, we've had users change channels in different places, this inevitably leads to confusion. With a chan_voter system, we can run the same UHF CB channel across the arena, and access it anywhere. Andrew had said to me "Shane, do you know how much such a system would cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how much would a PROPRIETARY system cost us? Anyway, I hope I have Jim and Rameshes blessing on this one - they did some great work, and I know it must've been a letdown to find out the hardware simply wasn't up to the task. Believe me, this isn't the first story I've heard about the lacklustre I/O performance of the RPi, and it won't be the last. But by using their work on a much stronger (I hope!) platform that it still ARM Linux based, I hope to circumvent at least one problem with the RPi. And its only $11 more before shipping! Looks like I'm going to be reading the Allwinnner A10 device spec sheet now, huh? =) Thanks for putting up with my ramble everyone. Shane.
Hi again, Just did some quick research on the schematics of the Cubieboard and the datasheet of the Allwinner A10 device - the EMAC for ethernet is completely separate from the three on-chip USB that are routed out to the two USB host and one USB-OTG port. So these are separate channels for the communications in all cases, not one on-chip (and a poor one at that) shared amongst at least three devices on the RPi. Interesting... On Fri, Dec 28, 2012 at 6:56 AM, Shane Morris <edgecomberts@gmail.com> wrote:
Hi all,
I was thinking, even though the RaspberryPi can't handle the audio stream from a URI due to the limitations of the USB bus, what is the ethernet performance like? I imagine it wouldn't be terribly good, due to the fact the ethernet swings off the USB, but hear me out...
chan_voter is a module that communicates via ethernet, am I correct? It uses an RTCM connected over an ethernet bus to communicate the voice data around, and I can imagine, at a low codec rate like GSM or even Speex, throughput wouldn't be as excessive as raw sound data coming from a fob.
So my proposal is, before Jim and Ramesh throw out the baby with the bathwater, and consign the RPi effort to the dust, why not take the work, which I believe involves getting Zaptel/ DAHDI to work with the RPi, and apply it to a purely chan_voter system? Yes, I know the chan_voter is dependant upon app_rpt, and in the future, someone, somewhere, is going to try to hook up a sound fob, and miserably complain it doesn't work, but we get the same questions about Asterisk 1.8 over and over too, right?
The advantages here are manyfold - again, low power consumption comes into the game, everyone knows I personally need as low a power consumption as I can get. The fact the RTCM data (ie, VoIP over ethernet) is much more suited to the infrastructure on the RPi is a good thing here too. The fact that normal Asterisk just runs, and runs well, on RPi is another motivating factor - my friend Andrew is running his house PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. And yes, simply the cool factor - who else can say they run their voting repeater system off something the size of a credit card, with all the proprietary, messy, rack mounted stuff out there?
If Jim and Ramesh are unwilling, or unable, to help, due to the fact that the RPi is a bit of a letdown (I heard about the USB performance issues - ouch!), I would like to take their work, and apply it to a platform I think may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 I/Os? For $49, gets you something good, look it up, www.cubieboard.org - I got one for Christmas, and I thought it would be good for this. Its a Chinese Allwinnner A10 device.
Since I have gone beyond just simple URI systems since Jim introduced me to the RTCM, I would like to get this to work. I recognised the RTCM did something I was talking to Andrew about on the way home from Expedition in October of this year - "Wouldn't it be nice, Andrew, if we could have a voting system that allows us the flexibility to run an Expeditions communications in such a way that make it simply easy for us, and easy for the users?" Before, we've had users change channels in different places, this inevitably leads to confusion. With a chan_voter system, we can run the same UHF CB channel across the arena, and access it anywhere.
Andrew had said to me "Shane, do you know how much such a system would cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how much would a PROPRIETARY system cost us?
Anyway, I hope I have Jim and Rameshes blessing on this one - they did some great work, and I know it must've been a letdown to find out the hardware simply wasn't up to the task. Believe me, this isn't the first story I've heard about the lacklustre I/O performance of the RPi, and it won't be the last. But by using their work on a much stronger (I hope!) platform that it still ARM Linux based, I hope to circumvent at least one problem with the RPi. And its only $11 more before shipping!
Looks like I'm going to be reading the Allwinnner A10 device spec sheet now, huh? =)
Thanks for putting up with my ramble everyone.
Shane.
My thought on this would be if it couldn't handle the DSP and had to rely on simple USB then it wouldn't be able to work as a voter because it wouldn't be able to read the RSSI of the discriminator audio. I may be way off on my thought, but I know it needs DSP for the discriminator audio. Corey N3FE -----Original Message----- From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Shane Morris Sent: Thursday, December 27, 2012 2:56 PM To: app_rpt mailing list Subject: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) Hi all, I was thinking, even though the RaspberryPi can't handle the audio stream from a URI due to the limitations of the USB bus, what is the ethernet performance like? I imagine it wouldn't be terribly good, due to the fact the ethernet swings off the USB, but hear me out... chan_voter is a module that communicates via ethernet, am I correct? It uses an RTCM connected over an ethernet bus to communicate the voice data around, and I can imagine, at a low codec rate like GSM or even Speex, throughput wouldn't be as excessive as raw sound data coming from a fob. So my proposal is, before Jim and Ramesh throw out the baby with the bathwater, and consign the RPi effort to the dust, why not take the work, which I believe involves getting Zaptel/ DAHDI to work with the RPi, and apply it to a purely chan_voter system? Yes, I know the chan_voter is dependant upon app_rpt, and in the future, someone, somewhere, is going to try to hook up a sound fob, and miserably complain it doesn't work, but we get the same questions about Asterisk 1.8 over and over too, right? The advantages here are manyfold - again, low power consumption comes into the game, everyone knows I personally need as low a power consumption as I can get. The fact the RTCM data (ie, VoIP over ethernet) is much more suited to the infrastructure on the RPi is a good thing here too. The fact that normal Asterisk just runs, and runs well, on RPi is another motivating factor - my friend Andrew is running his house PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. And yes, simply the cool factor - who else can say they run their voting repeater system off something the size of a credit card, with all the proprietary, messy, rack mounted stuff out there? If Jim and Ramesh are unwilling, or unable, to help, due to the fact that the RPi is a bit of a letdown (I heard about the USB performance issues - ouch!), I would like to take their work, and apply it to a platform I think may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 I/Os? For $49, gets you something good, look it up, www.cubieboard.org - I got one for Christmas, and I thought it would be good for this. Its a Chinese Allwinnner A10 device. Since I have gone beyond just simple URI systems since Jim introduced me to the RTCM, I would like to get this to work. I recognised the RTCM did something I was talking to Andrew about on the way home from Expedition in October of this year - "Wouldn't it be nice, Andrew, if we could have a voting system that allows us the flexibility to run an Expeditions communications in such a way that make it simply easy for us, and easy for the users?" Before, we've had users change channels in different places, this inevitably leads to confusion. With a chan_voter system, we can run the same UHF CB channel across the arena, and access it anywhere. Andrew had said to me "Shane, do you know how much such a system would cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how much would a PROPRIETARY system cost us? Anyway, I hope I have Jim and Rameshes blessing on this one - they did some great work, and I know it must've been a letdown to find out the hardware simply wasn't up to the task. Believe me, this isn't the first story I've heard about the lacklustre I/O performance of the RPi, and it won't be the last. But by using their work on a much stronger (I hope!) platform that it still ARM Linux based, I hope to circumvent at least one problem with the RPi. And its only $11 more before shipping! Looks like I'm going to be reading the Allwinnner A10 device spec sheet now, huh? =) Thanks for putting up with my ramble everyone. Shane. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users -- This message was scanned and is believed to be clean. Click here to report this message as spam. http://simba.repeater.net/cgi-bin/learn-msg.cgi?id=E18C4221F.A9108
participants (2)
-
Corey Dean -
Shane Morris