For a project that I work on, we have a 32-bit build "server" running on Windows XP Professional. We are starting to expand this project to support 64-bit systems. No problem, right? Visual Studio has cross-compilers for x64 machines. So, we can still use our 32-bit system to build 64-bit binaries.
Umm.. Sure... Something like that.. I spent a rather long weekend trying to figure out how to do this very thing. The problem that I ran in to is the UI for the project uses the QT libraries.
I started off trying to build the x64 QT libraries using the x64 compilers on a Windows XP development machine. I didn't get very far in the process before I hit a dead end. The build would bail out when it attempted to run qmake.exe. After beating my head on it for a bit, I realized that the build system that QT uses expects to compile tools like qmake, and then execute them to complete the rest of its build process. So, the build process would build qmake for the x64 architecture, then attempt to run it, which obviously wouldn't work. (Remember, I was on a 32 bit system.)
I suspect that someone that wanted to badly enough could work around this with various types of trickery. But, I happened to have an x64 machine kicking around my house, so I just built it on that machine, and then decided to try to move it to the 32-bit build system. The x64 build went smoothly when it was done on an x64 machine. (Imagine that!)
Of course, once I moved my shiny new x64 libraries over to the Windows XP build machine, nothing worked. It didn't work because all of the .exe files that were used to handle the QT magic were 64 bit binaries! So, to get things working, I had to find a way around it.
Since the tools that are used in compiling QT programs basically take some type of data (usually XML) and translate it to code that can be compiled. The code that is generated is nothing more than a text file that is then fed in to a compiler. So, it seemed that I might be able to replace some of the .exe files that QT was attempting to call, and end up with something that worked, even if it was something the QT guys would turn up their noses at.
My first attempt was to copy all of the .exe files from the /bin/ directory of a 32-bit install over the .exe files in the /bin/ directory of the 64-bit install. After doing this, I kicked off a build and waited to see what blew up so I could figure out how to fix it. To my surprise, the project built without complaining.
I figured it couldn't POSSIBLY be THAT easy. But, it looks like it is. The binary that was built seems to work on x64 versions of Windows when cross-compiled from a 32-bit version of Windows.
Friday, March 12, 2010
Friday, February 19, 2010
Hands on with the Unidata WPU7700 (and a Quickphones update)
First, two quick updates on the Quickphones QA-342. First, the battery on that phone finally died. The available information on the expected life of the battery seems to vary a bit depending on which site you are looking at. The site I purchased the phone from claims it should last 7 days. The Quickphones release notes claim 70 hours. Based on this, I figured if I got 70 hours out of it, I would call the battery life a success. After three days, the phone still showed 50% of the battery available. After 9 days, it was finally dead. To put some quick perspective on the battery life. This isn't a situation where I just put the phone on the desk and waited for it to die. I actually used it during that week. I probably spent 30-45 minutes talking on the phone. (Which, while not a lot of time, should have at least a small impact on the battery life of the phone.) So, the verdict on battery life for the Quickphones is an overwhelming two thumbs up.
Second, I heard back from the Quickphones guys. They said they are looking in to the multiple AP issue. If they could get this fixed, I would be sold on these phones for day to day use. As I mentioned in a previous post, the voice quality isn't great, and the shape of the phone could use some work. But, both of those things aren't annoying enough to keep me from using the phone.
However, while I was getting no response from Quickphones, I decided to pick up a Unidata WPU7700. From what I could tell, this phone offered the next best battery life in a Wifi phone.
The phone itself is built well, and feels pretty hefty. Not that I would recommend dropping it, but it does feel like it could take a drop or two. (Assuming the screen didn't break, of course.)
Out of the box, each button press resulted in a beeping noise. This was extremely irritating. Fortunately, hitting the menu button, and switching to the "sounds" menu, I was able to shut that off. This made the phone a lot more pleasant to use.
This phone quickly connected to my WPA2-PSK network. And, after figuring out how the text input worked, I was able to quickly get it signed on as an extension on my Asterisk box. So, I got on quickly to the first test I wanted to run. The battery life test.
I let the phone get a full charge, and then unplugged it from power and left it sitting on the desk. About 21 hours later, the phone was beeping and complaining it was low on power. This was shocking, to say the least. This phone was supposed to have 40 hours of stand-by battery time.
While configuring it, I had turned on the internal web server. So, I wondered if that was keeping the phone more awake that it needed to be. I shut it off, and charged the phone back up completely, and left it sitting on the desk again. About 21 hours later, the phone was again beeping and complaining that it was low on power.
Since I don't see any more options for adjusting the power savings on the phone, I have to conclude that the battery life on this phone is nowhere near what the manufacturer claims. (And down right pitiful compared to the Quickphones!)
As for the sound quality of this phone, it was quite good. It is on par with any cordless analog phone you would find.
One of the more interesting things about this phone is all of the crazy features it has. It has a small web browser built in, some text messaging functionality, a calculator, and a bunch of other little applets. For many, or perhaps most, of the applets, I can't see a point to them. It is functionality that exists on other pieces of equipment that exist in a normal business or even a house. The one feature the Unidata phone has that is great, is the ability to do 802.1X. (Or, WPA(2)-Enterprise, if you want to call it by that name.) I didn't test the functionality, since I have not had time. But, for businesses that care about security, this would be a major win.
Second, I heard back from the Quickphones guys. They said they are looking in to the multiple AP issue. If they could get this fixed, I would be sold on these phones for day to day use. As I mentioned in a previous post, the voice quality isn't great, and the shape of the phone could use some work. But, both of those things aren't annoying enough to keep me from using the phone.
However, while I was getting no response from Quickphones, I decided to pick up a Unidata WPU7700. From what I could tell, this phone offered the next best battery life in a Wifi phone.
The phone itself is built well, and feels pretty hefty. Not that I would recommend dropping it, but it does feel like it could take a drop or two. (Assuming the screen didn't break, of course.)
Out of the box, each button press resulted in a beeping noise. This was extremely irritating. Fortunately, hitting the menu button, and switching to the "sounds" menu, I was able to shut that off. This made the phone a lot more pleasant to use.
This phone quickly connected to my WPA2-PSK network. And, after figuring out how the text input worked, I was able to quickly get it signed on as an extension on my Asterisk box. So, I got on quickly to the first test I wanted to run. The battery life test.
I let the phone get a full charge, and then unplugged it from power and left it sitting on the desk. About 21 hours later, the phone was beeping and complaining it was low on power. This was shocking, to say the least. This phone was supposed to have 40 hours of stand-by battery time.
While configuring it, I had turned on the internal web server. So, I wondered if that was keeping the phone more awake that it needed to be. I shut it off, and charged the phone back up completely, and left it sitting on the desk again. About 21 hours later, the phone was again beeping and complaining that it was low on power.
Since I don't see any more options for adjusting the power savings on the phone, I have to conclude that the battery life on this phone is nowhere near what the manufacturer claims. (And down right pitiful compared to the Quickphones!)
As for the sound quality of this phone, it was quite good. It is on par with any cordless analog phone you would find.
One of the more interesting things about this phone is all of the crazy features it has. It has a small web browser built in, some text messaging functionality, a calculator, and a bunch of other little applets. For many, or perhaps most, of the applets, I can't see a point to them. It is functionality that exists on other pieces of equipment that exist in a normal business or even a house. The one feature the Unidata phone has that is great, is the ability to do 802.1X. (Or, WPA(2)-Enterprise, if you want to call it by that name.) I didn't test the functionality, since I have not had time. But, for businesses that care about security, this would be a major win.
Monday, February 15, 2010
QuickPhones follow up....
Well, it has been a bit over a week with the QuickPhones QA-342. So, I thought I would follow up with my view on the hardware so far.
So far, I have not had time to dig in to the multiple AP problem any farther than I had during the last post. But, to get the phone working, I set up a NetGear AP with a different SSID. After doing that, the phone has been reasonably stable.
One of the key things that interested me in this phone was the battery life. So, I let it charge over the weekend that I got it, and have left it powered on, our of the cradle for the last 7 days. Looking at the phone just now, it shows the battery is at 75%. As a result, this phone certainly meets my needs for battery life!
I REALLY wish I could say that the rest of the phone meets my needs. Since I started using it, I have come up with a pretty hefty list of complaints about the phone. Obviously, the first one is with the multi-AP support.
I cut the QuickPhones guys a lot of slack initially about this. Mostly because they were so responsive about getting me access to the 4.0 firmware. It seemed like they were a solid company that really wanted to make a top-notch product. In the last week, my opinion has changed. Early last week, I e-mailed my list of issues to their support people, and included information about my credentials for wireless and offered to help them in debugging the issues. That e-mail seems to have fallen on deaf ears. Later in the week, I pinged them again to verify that they had gotten my first e-mail. Again, I got no response.
Now, let me go off on a bit of a side rant here. I did something in my e-mail to support that I rarely do. I gave them information about my credentials as a wireless networking professional, and wireless network software developer. I generally don't do this because I have been in too many big box electronics stores where the sales people claim to be experts on a topic by nature of working for that store. I don't want to come off sounding like those people. That said, I did include that information in my e-mail to their support people. The main reason being that I liked the build of the phone and wanted to help them get the issues hammered out so I could purchase more of them.
Which leads me back to the additional issues I have seen. The sound quality on the phone is sub-par. There was a lot of static in the background when I was talking to someone. This wasn't comfort noise type static, this was pops and clicks as if packets were being lost in transit. Since it is wireless, and running at 2.4Ghz, I can understand a little bit of that. But, when I compare it to my older D-Link phone the sound quality is night and day. The D-Link was crystal clear, the QuickPhones was less than ideal.
The other sound quality issue I had is with the volume. I will be the first one to admit that I have been to too many loud concerts, and played my stereo louder than I should. So, I don't have the best hearing in the world. So, I usually like to have my phones turned up fairly loud so I can hear everything clearly. When the QuickPhones was to quiet, I tried to use the volume buttons on the side of the phone to increase the in-call volume. From what I could tell, the volume buttons didn't do anything. Again, I have not had time to play with the phone enough to determine if the volume is all the way up, or if the buttons just don't work how I would expect. But, the sound really isn't good.
Which leads me to the next sound related issue. The front of the phone is curved. If the sound on the phone was better, I suspect I wouldn't have noticed this. But, since I was straining to hear the sound, I noticed the curvature of the phone kept it from feeling like it fit nicely against my ear. While this seems like a nit, keep in mind that the vast majority of phones out there are flat. I have to believe there is a reason for that.
So, what comes next? Well, I am supposed to take delivery of a Unidata WPU7700 phone today. It should be interesting to see how it stacks up to the D-Link and the QuickPhones. I also took delivery of an OpenVox A400E board about an hour ago. So, I expect to blog a bit more about the installation an effort involved in getting those running.
So far, I have not had time to dig in to the multiple AP problem any farther than I had during the last post. But, to get the phone working, I set up a NetGear AP with a different SSID. After doing that, the phone has been reasonably stable.
One of the key things that interested me in this phone was the battery life. So, I let it charge over the weekend that I got it, and have left it powered on, our of the cradle for the last 7 days. Looking at the phone just now, it shows the battery is at 75%. As a result, this phone certainly meets my needs for battery life!
I REALLY wish I could say that the rest of the phone meets my needs. Since I started using it, I have come up with a pretty hefty list of complaints about the phone. Obviously, the first one is with the multi-AP support.
I cut the QuickPhones guys a lot of slack initially about this. Mostly because they were so responsive about getting me access to the 4.0 firmware. It seemed like they were a solid company that really wanted to make a top-notch product. In the last week, my opinion has changed. Early last week, I e-mailed my list of issues to their support people, and included information about my credentials for wireless and offered to help them in debugging the issues. That e-mail seems to have fallen on deaf ears. Later in the week, I pinged them again to verify that they had gotten my first e-mail. Again, I got no response.
Now, let me go off on a bit of a side rant here. I did something in my e-mail to support that I rarely do. I gave them information about my credentials as a wireless networking professional, and wireless network software developer. I generally don't do this because I have been in too many big box electronics stores where the sales people claim to be experts on a topic by nature of working for that store. I don't want to come off sounding like those people. That said, I did include that information in my e-mail to their support people. The main reason being that I liked the build of the phone and wanted to help them get the issues hammered out so I could purchase more of them.
Which leads me back to the additional issues I have seen. The sound quality on the phone is sub-par. There was a lot of static in the background when I was talking to someone. This wasn't comfort noise type static, this was pops and clicks as if packets were being lost in transit. Since it is wireless, and running at 2.4Ghz, I can understand a little bit of that. But, when I compare it to my older D-Link phone the sound quality is night and day. The D-Link was crystal clear, the QuickPhones was less than ideal.
The other sound quality issue I had is with the volume. I will be the first one to admit that I have been to too many loud concerts, and played my stereo louder than I should. So, I don't have the best hearing in the world. So, I usually like to have my phones turned up fairly loud so I can hear everything clearly. When the QuickPhones was to quiet, I tried to use the volume buttons on the side of the phone to increase the in-call volume. From what I could tell, the volume buttons didn't do anything. Again, I have not had time to play with the phone enough to determine if the volume is all the way up, or if the buttons just don't work how I would expect. But, the sound really isn't good.
Which leads me to the next sound related issue. The front of the phone is curved. If the sound on the phone was better, I suspect I wouldn't have noticed this. But, since I was straining to hear the sound, I noticed the curvature of the phone kept it from feeling like it fit nicely against my ear. While this seems like a nit, keep in mind that the vast majority of phones out there are flat. I have to believe there is a reason for that.
So, what comes next? Well, I am supposed to take delivery of a Unidata WPU7700 phone today. It should be interesting to see how it stacks up to the D-Link and the QuickPhones. I also took delivery of an OpenVox A400E board about an hour ago. So, I expect to blog a bit more about the installation an effort involved in getting those running.
Sunday, February 7, 2010
Hands-on with the Quickphone QA-342 Wifi Phone
I have been slowly replacing the old analog phones around my house with some nitfy IP phones. Since I am someone that doesn't like to get too tied down by one vendor, I am using a variety of different phones. (Okay, to be fair, it isn't just a one vendor issue. It is also phones that I can get cheap. ;)
To that end, I have replaced my office phone with a Cisco 7960, the phone in my basement with a Polycom 501, and the phone in my kitchen with a Budgetone (model number escapes me at the moment.) All of these phones are tied to my Asterisk box running in the basement.
At this point, there is only one set of phones in my house that are not IP based. Those would be the old stand-by cordless phones that are probably the second most used phones in the house.
Some time ago, I picked up one of the D-Link "flip-phone" SIP phones. (Model DPH-540, IIRC.) The phone worked surprisingly well for a gen 1 wifi phone. The range was great, the sound was good, but the battery was so horrible that the phone was only usable as a toy. Cordless phones around my house can sit out of their charging station for days (sometimes weeks) without being put back. Needless to say, the D-Link was never charged when I wanted to use it.
So, I started to look around to see what other options were out there. My criteria were somewhat simple. The phone needed to have a significant stand-by time, several days at a minimum. Obviously the phone needed to work with some form of secure SSID, WPA-Enterprise would be great, but I would settle for WPA-PSK.
After some digging, I came up with two phones that looked like they would do what I needed. They were the Quickphones QA-342, and the Unidata WPU7700. I managed to track down the Quickphones for about $130, while the best price I could find on the Unidata was $160. So, I decided to go with the Quickphones.
My goal was that this blog post would be a short entry, made about 7 days after the phone arrived. The D-Link had shown me that there are stable wifi SIP stacks out there, so I assumed that the main thing I would looking at with the Quickphones was the battery life.
Boy, was I wrong! The first problem I ran in to was right out of the box. When I scanned for wireless networks, nothing showed up. This seemed insane to me, since there are a HUGE number of wireless networks in my area. (My house alone probably has 12 SSIDs!!!) After messing with the phone for a while, I did manage to see one or two SSIDs every now and then, but never the SSIDs I wanted to use.
In past years, I have worked with the Interop iLabs people on wireless related demos for the shows in Las Vegas and New York. So, I knew that many wireless implementations have silly restrictions on the size of the scan buffer. So, I decided to pair down the number of SSIDs that the phone could see. First, I turned off all of the wireless in my house. After a reboot, the phone could now see all of my neighbors wireless networks! So, I paired down the list of SSIDs I was broadcasting in my house to just the 4 that I needed to use the most.
I rebooted the phone, thinking I had solved the problem, and again, I saw no scan data. So, I hopped over to the Quickphones site to check that my firmware was up to date. There were two firmwares available on their site. However, version 4 required a license key, so I fired an e-mail off to the Quickphones folks to see if I qualified for the upgrade, and then loaded version 3 on my phone.
Version 3 made no difference. I still couldn't see my SSIDs in the scan. Since I had read of some of the reviews about the phone that it had issues with multiple APs on the same SSID, I shut down all of the radios in my house except the one that was nearest to me. Surprisingly enough, the phone could now see the network, connect to it, and make a call. Thinking that it might be some weirdness in the software that prevented the initial setup when multiple APs were around, I turned the other APs back on, and rebooted the phone. After the reboot, the phone just bounced between scanning, and joining.
The next day, I checked my e-mail and found that the Quickphones people had responded to my initial e-mail within an hour of my sending it. (Downright amazing if you ask me. I can't tell you how many companies have ignored e-mails from me!) In the e-mail was the code I needed to upgrade to version 4. So, I quickly loaded up version 4, did a master reset, and a fresh scan.
My SSIDs show up this time! Life was finally going to be good! So, I attempted to connect to the SSID, but wasn't able to. Every time I put the key in, it complained that it was incorrect. So, I shut down all but one of the APs again, and connected. That method still worked at least!
Once I had done this, I went in to the settings, and turned on the new setting for multiple AP support. I then turned my other APs back on. The phone remained connected to the AP that I was sitting next to! Life again, seemed to be looking up. So, I rebooted the phone to see what would happen. After the reboot, the phone went between scanning and network down mode a few times, then switched to joining, and proceeded to sit there on that screen for a good half hour.
At this point, I am starting to run out of ideas. It is unclear to me if the issue I am running in to is multiple APs, or if it is some incompatibility with the Trapeze wireless gear that I am using. Fortunately, I have a small pile of wireless gear sitting around my house, so I should be able to narrow it down. In the mean time, I am going to also launch a pre-emptive e-mail to the Quickphones folks and see if they are aware of this issue, and if I can help them figure out what it wrong.
More as it develops.....
To that end, I have replaced my office phone with a Cisco 7960, the phone in my basement with a Polycom 501, and the phone in my kitchen with a Budgetone (model number escapes me at the moment.) All of these phones are tied to my Asterisk box running in the basement.
At this point, there is only one set of phones in my house that are not IP based. Those would be the old stand-by cordless phones that are probably the second most used phones in the house.
Some time ago, I picked up one of the D-Link "flip-phone" SIP phones. (Model DPH-540, IIRC.) The phone worked surprisingly well for a gen 1 wifi phone. The range was great, the sound was good, but the battery was so horrible that the phone was only usable as a toy. Cordless phones around my house can sit out of their charging station for days (sometimes weeks) without being put back. Needless to say, the D-Link was never charged when I wanted to use it.
So, I started to look around to see what other options were out there. My criteria were somewhat simple. The phone needed to have a significant stand-by time, several days at a minimum. Obviously the phone needed to work with some form of secure SSID, WPA-Enterprise would be great, but I would settle for WPA-PSK.
After some digging, I came up with two phones that looked like they would do what I needed. They were the Quickphones QA-342, and the Unidata WPU7700. I managed to track down the Quickphones for about $130, while the best price I could find on the Unidata was $160. So, I decided to go with the Quickphones.
My goal was that this blog post would be a short entry, made about 7 days after the phone arrived. The D-Link had shown me that there are stable wifi SIP stacks out there, so I assumed that the main thing I would looking at with the Quickphones was the battery life.
Boy, was I wrong! The first problem I ran in to was right out of the box. When I scanned for wireless networks, nothing showed up. This seemed insane to me, since there are a HUGE number of wireless networks in my area. (My house alone probably has 12 SSIDs!!!) After messing with the phone for a while, I did manage to see one or two SSIDs every now and then, but never the SSIDs I wanted to use.
In past years, I have worked with the Interop iLabs people on wireless related demos for the shows in Las Vegas and New York. So, I knew that many wireless implementations have silly restrictions on the size of the scan buffer. So, I decided to pair down the number of SSIDs that the phone could see. First, I turned off all of the wireless in my house. After a reboot, the phone could now see all of my neighbors wireless networks! So, I paired down the list of SSIDs I was broadcasting in my house to just the 4 that I needed to use the most.
I rebooted the phone, thinking I had solved the problem, and again, I saw no scan data. So, I hopped over to the Quickphones site to check that my firmware was up to date. There were two firmwares available on their site. However, version 4 required a license key, so I fired an e-mail off to the Quickphones folks to see if I qualified for the upgrade, and then loaded version 3 on my phone.
Version 3 made no difference. I still couldn't see my SSIDs in the scan. Since I had read of some of the reviews about the phone that it had issues with multiple APs on the same SSID, I shut down all of the radios in my house except the one that was nearest to me. Surprisingly enough, the phone could now see the network, connect to it, and make a call. Thinking that it might be some weirdness in the software that prevented the initial setup when multiple APs were around, I turned the other APs back on, and rebooted the phone. After the reboot, the phone just bounced between scanning, and joining.
The next day, I checked my e-mail and found that the Quickphones people had responded to my initial e-mail within an hour of my sending it. (Downright amazing if you ask me. I can't tell you how many companies have ignored e-mails from me!) In the e-mail was the code I needed to upgrade to version 4. So, I quickly loaded up version 4, did a master reset, and a fresh scan.
My SSIDs show up this time! Life was finally going to be good! So, I attempted to connect to the SSID, but wasn't able to. Every time I put the key in, it complained that it was incorrect. So, I shut down all but one of the APs again, and connected. That method still worked at least!
Once I had done this, I went in to the settings, and turned on the new setting for multiple AP support. I then turned my other APs back on. The phone remained connected to the AP that I was sitting next to! Life again, seemed to be looking up. So, I rebooted the phone to see what would happen. After the reboot, the phone went between scanning and network down mode a few times, then switched to joining, and proceeded to sit there on that screen for a good half hour.
At this point, I am starting to run out of ideas. It is unclear to me if the issue I am running in to is multiple APs, or if it is some incompatibility with the Trapeze wireless gear that I am using. Fortunately, I have a small pile of wireless gear sitting around my house, so I should be able to narrow it down. In the mean time, I am going to also launch a pre-emptive e-mail to the Quickphones folks and see if they are aware of this issue, and if I can help them figure out what it wrong.
More as it develops.....
Tuesday, December 1, 2009
Love and Hate with Asterisk
For a year or two I have been running an Asterisk server. It has been wonderful. Recently, I wanted to add the new Skype functionality to Asterisk, so it required that I move from an old Apple X Serve to an x86 based machine. In the process, I figured I would upgrade from Asterisk 1.4, to 1.6. It should be simple, right?
Umm.. Yeah... Something like that. My configuration consists of a Sipura/Linksys/Cisco SPA-3102, the Asterisk server, and a collection of random VoIP phones around the house. By just moving the configurations from the old server to the new one, I was able to get the VoIP phones to talk to each other, along with being able to make outbound PSTN calls. This left me with three major headaches for the migration.
1. Calls from VoIP phones to the analog port on the SPA failed.
2. Inbound calls from PSTN->Asterisk weren't routed to the phones.
3. My custom AEL scripts to stop annoying people were broken.
Fixing #1 was pretty easy. The failure was coming from the fact that I had some events in the extension that couldn't be executed, so Asterisk would stop working through the list. (Or, in a nutshell, #3 was the cause of #1.) By changing the events back to a basic "ring the phone" list, this problem was solved.
#2 was a real pain. The solution was ultimately stupid/annoying. (Isn't it always!?) In the sip.conf file, I had "insecure=very" set in the [spa3k-pstn] configuration. It would seem this doesn't mean the same thing in 1.6 that it did in 1.4. Changing the line to "insecure=invite" resolved that problem, and allowed inbound calls to work once again.
#3 is an adventure I have not yet undertaken. Stay tuned...
Umm.. Yeah... Something like that. My configuration consists of a Sipura/Linksys/Cisco SPA-3102, the Asterisk server, and a collection of random VoIP phones around the house. By just moving the configurations from the old server to the new one, I was able to get the VoIP phones to talk to each other, along with being able to make outbound PSTN calls. This left me with three major headaches for the migration.
1. Calls from VoIP phones to the analog port on the SPA failed.
2. Inbound calls from PSTN->Asterisk weren't routed to the phones.
3. My custom AEL scripts to stop annoying people were broken.
Fixing #1 was pretty easy. The failure was coming from the fact that I had some events in the extension that couldn't be executed, so Asterisk would stop working through the list. (Or, in a nutshell, #3 was the cause of #1.) By changing the events back to a basic "ring the phone" list, this problem was solved.
#2 was a real pain. The solution was ultimately stupid/annoying. (Isn't it always!?) In the sip.conf file, I had "insecure=very" set in the [spa3k-pstn] configuration. It would seem this doesn't mean the same thing in 1.6 that it did in 1.4. Changing the line to "insecure=invite" resolved that problem, and allowed inbound calls to work once again.
#3 is an adventure I have not yet undertaken. Stay tuned...
Sunday, October 18, 2009
Acer Aspire Revo as a MythTV frontend
When Acer released the Aspire Revo, a lot of people seemed to think it would make a good front-end for a MythTV box. The price point seemed reasonable, the hardware seemed capable, and the size was just right.
However, Acer decided not to release it in the US at launch. Unfortunately, my trek to the UK for the year had already passed by the time it was released. (I was also a little too early for the start of the Depeche Mode tour, but that is a different story.) So, I looked around in Japan while I was there this summer, and was unable to locate one in either Akiba or Den-den town.
But, it was unclear that it would have worked well considering only SVN had the needed VDPAU support for MythTV. But, when the Revo FINALLY showed up at Newegg for a mere $199.99, I jumpped and snapped one up.
I'll spare you specs of the box, since it is posted all over the net. If you are really curious which one I have, you can see the specs here : http://www.newegg.com/Product/Product.aspx?Item=N82E16883103228&Tpk=Acer%20Aspire%20Revo .
Once I got the box, I loaded Gentoo Linux on it, and grabbed the 0.22rc1 release of MythTV from the MythTV site. I also loaded up the latest beta driver from NVidia's web site so I could be sure to get support for the ION chip in this box.
In a nutshell, the Revo is a pretty good option for someone looking for a fairly no frills front end for MythTV. There are just a couple of issues to watch out for.
First, MythTV wants your VDPAU enabled board to have 512 Megs of RAM, minimum. In the stock configuration I ordered from NewEgg, the box only comes with 1 Gig of RAM. The maximum amount of RAM that the BIOS will allow to be assigned to video is only 256 Meg. In my initial testing, this worked okay, but it is always a good idea to meet the specs of the software you are running. (It will usually result in less pain.)
My theory was that if I upgraded the RAM, perhaps the BIOS would let me assign more memory to the video card. So, I dug up some SODIMMs that I had laying around the house. (Yes, I know.. Most people don't have SODIMMs laying around the house. ;) A little bit searching around on Google, and I found this video on how to open the case : http://www.youtube.com/watch?v=7ayQOyTEWRw . The video suggests the use of a flat-head screw driver to pry the case open, but I found that less damage was done to the case if I used the slot cover from a desktop case instead.
Once the box was open, I slapped the 1 Gig SODIMM in the available slot, booted the machine up, and checked the BIOS. It allowed me to up the video memory from 256M to 512M. Mission accomplished!
So, how well does it REALLY work? I think the answer to this will come only after a few weeks of using it. But, in my tests, with VDPAU running, and watching live TV from a 1080i source, the CPU sat at about 12-13%. This was without any form of deinterlacing enabled, so it may well be higher when I get around to messing with that. The box also managed to play DVDs, and FLAC audio with no problems.
So, a Myth frontend for $199.99? There has to be SOMETHING wrong with it! It is too good to be true! Well, I am not sure I would say that there is anything "wrong" with the box, but there are some things that you may want to consider before picking up a Revo. One of the most glaring is the lack of any form of digial audio out. For me, this is a non-issue since I am hooking it up to a TV that only has stereo anyway. But, for some, this may be a good enough reason to steer clear of this system. The box also has two other annoyances. First, the only audio jack is on the front. So, if the box sits somewhere that people might see it, the audio cable will be sticking out. Second, the power LED on the box is a bright white LED on one of the corners. If you were going to put this in a room where you wanted it to be dark at night, this could be an issue. However, solving this is fairly easy. A little bit of painters tape from your local hardware store should be enough to dim the light on the box.
If you need a front-end that is similar to the Revo, but has optical or other features, you might check out the mainboards that NewEgg sells. I saw a few of the Atom boards with the ION chips on them. Many of those included all of the outputs you could possibly want.
But, at the end of the day, a board with an Atom processor, and an NVidia ION chip is plenty for driving a MythTV frontend.
However, Acer decided not to release it in the US at launch. Unfortunately, my trek to the UK for the year had already passed by the time it was released. (I was also a little too early for the start of the Depeche Mode tour, but that is a different story.) So, I looked around in Japan while I was there this summer, and was unable to locate one in either Akiba or Den-den town.
But, it was unclear that it would have worked well considering only SVN had the needed VDPAU support for MythTV. But, when the Revo FINALLY showed up at Newegg for a mere $199.99, I jumpped and snapped one up.
I'll spare you specs of the box, since it is posted all over the net. If you are really curious which one I have, you can see the specs here : http://www.newegg.com/Product/Product.aspx?Item=N82E16883103228&Tpk=Acer%20Aspire%20Revo .
Once I got the box, I loaded Gentoo Linux on it, and grabbed the 0.22rc1 release of MythTV from the MythTV site. I also loaded up the latest beta driver from NVidia's web site so I could be sure to get support for the ION chip in this box.
In a nutshell, the Revo is a pretty good option for someone looking for a fairly no frills front end for MythTV. There are just a couple of issues to watch out for.
First, MythTV wants your VDPAU enabled board to have 512 Megs of RAM, minimum. In the stock configuration I ordered from NewEgg, the box only comes with 1 Gig of RAM. The maximum amount of RAM that the BIOS will allow to be assigned to video is only 256 Meg. In my initial testing, this worked okay, but it is always a good idea to meet the specs of the software you are running. (It will usually result in less pain.)
My theory was that if I upgraded the RAM, perhaps the BIOS would let me assign more memory to the video card. So, I dug up some SODIMMs that I had laying around the house. (Yes, I know.. Most people don't have SODIMMs laying around the house. ;) A little bit searching around on Google, and I found this video on how to open the case : http://www.youtube.com/watch?v=7ayQOyTEWRw . The video suggests the use of a flat-head screw driver to pry the case open, but I found that less damage was done to the case if I used the slot cover from a desktop case instead.
Once the box was open, I slapped the 1 Gig SODIMM in the available slot, booted the machine up, and checked the BIOS. It allowed me to up the video memory from 256M to 512M. Mission accomplished!
So, how well does it REALLY work? I think the answer to this will come only after a few weeks of using it. But, in my tests, with VDPAU running, and watching live TV from a 1080i source, the CPU sat at about 12-13%. This was without any form of deinterlacing enabled, so it may well be higher when I get around to messing with that. The box also managed to play DVDs, and FLAC audio with no problems.
So, a Myth frontend for $199.99? There has to be SOMETHING wrong with it! It is too good to be true! Well, I am not sure I would say that there is anything "wrong" with the box, but there are some things that you may want to consider before picking up a Revo. One of the most glaring is the lack of any form of digial audio out. For me, this is a non-issue since I am hooking it up to a TV that only has stereo anyway. But, for some, this may be a good enough reason to steer clear of this system. The box also has two other annoyances. First, the only audio jack is on the front. So, if the box sits somewhere that people might see it, the audio cable will be sticking out. Second, the power LED on the box is a bright white LED on one of the corners. If you were going to put this in a room where you wanted it to be dark at night, this could be an issue. However, solving this is fairly easy. A little bit of painters tape from your local hardware store should be enough to dim the light on the box.
If you need a front-end that is similar to the Revo, but has optical or other features, you might check out the mainboards that NewEgg sells. I saw a few of the Atom boards with the ION chips on them. Many of those included all of the outputs you could possibly want.
But, at the end of the day, a board with an Atom processor, and an NVidia ION chip is plenty for driving a MythTV frontend.
Monday, October 12, 2009
Of Androids and USB
In general, I am a fan of the Android phone. (In case you couldn't tell.) But, I just spend 2 hours fighting with a myTouch3g trying to get it set up so I could use it as a debug target.
Now, in general, I suspect most people won't have this type of problem, since I am fairly sure it is the result of previously having my system configured to debug on my ADP1. But, if you happen to run in to this problem, here are some things that might help.
1. Download USBDeview from http://www.nirsoft.net/utils/usb_devices_view.html .
2. Unplug your phone from the computer.
3. Run USBDeview, find everything listed as an Android device, and uninstall it.
4. In the Android SDK, run "adb kill-server"
5. Make sure your phone is configured for development, and plug it back in.
This should cause Windows to find it again as if it had never been plugged in. It should give you the option of installing the ADB driver from the latest version of the SDK.
Once I had done this, the phone didn't immediately show up. To fix that, I left the phone connected, and toggled the development checkbox. After that, it showed up and I could use it.
Now, in general, I suspect most people won't have this type of problem, since I am fairly sure it is the result of previously having my system configured to debug on my ADP1. But, if you happen to run in to this problem, here are some things that might help.
1. Download USBDeview from http://www.nirsoft.net/utils/usb_devices_view.html .
2. Unplug your phone from the computer.
3. Run USBDeview, find everything listed as an Android device, and uninstall it.
4. In the Android SDK, run "adb kill-server"
5. Make sure your phone is configured for development, and plug it back in.
This should cause Windows to find it again as if it had never been plugged in. It should give you the option of installing the ADB driver from the latest version of the SDK.
Once I had done this, the phone didn't immediately show up. To fix that, I left the phone connected, and toggled the development checkbox. After that, it showed up and I could use it.
Subscribe to:
Comments (Atom)