|
|
|
[
Permlink
| « Hide
]
NixNerd Cosmos added a comment - 13/Mar/07 03:05 PM
Any news on the progress of the Linux Voice Beta - Lindens please?
I've checked on this and we are not currently planning on having a Linux voice beta client for testing. More information when it's available.
Thanks for the update Jeska - it is much appreciated
We do plan on eventually releasing voice to the Linux client, following the launch of the Windows and mac version. Sorry I don't have more specific details.
Thanks again Jeska - it's so good of you to let us linux users know what's being planned regarding the voice client
Vote "Delay this".
Right now the alpha quality Linux client really needs alot more work in more important areas, in fact all three clients need it. I call for all work on voice bloat and teledildonics bloat to be scrapped until the existing viewer codebase is up to scratch and relatively bug free. Not currently planning... eventually releasing... Don't tell us that we'll going to have to wait another what, four years to get voice into the Linux client? It took us that long just to get a Linux client to begin with, and then half way though Icculus Linden was dropped because he couldn't do the client anymore.
It can't be that hard. Take a look at the Speex codec and a third-party two-way system called Speextalk. Both are open source and the latter you can make into a P2P system, shifting the audio handling and attenuation to the client itself. I'm mucking around with Speextalk to get my Zaurus C-3100 talking to my laptop so I can speak into Teamspeak while I'm walking around the house. Drake, luckily it's not Linden Labs' fault that a Linux voice client isn't out. Tofu mentioned in the forum that internally he's ready to build it, but they're waiting for a Linux binary blob(blech!) from the voice vendor. So I'd say the best question for jeska right now would be, "Who's the vendor, so we can bug, er, help them to get their blob out the door sooner rather than later?"
It's Vivox.
And no matter what they eventually provide, it will not be distributable, as the codec being used is patented and is not freely licensed. Cool!
So Linux's GNU / Open Source heritage saves me from voice chat? >>WICKED<< I LOVE Linux more & more on a daily basis! Lack of voice on Linux should delay the entire voice project. If you cant support something on all the platforms your customers use, you should not offer it.
"Lack of voice on Linux should delay the entire voice project. If you cant support something on all the platforms your customers use, you should not offer it."
I agree! Wow more proprietary crap, really? I suppose there must be a good reason for it, I cant for the life of me think of one, but there must be. If you are paranoid, you should start assuming, now that voice is in the official build, that people will be using voice all over the place and saying, "I bet that guy uses linux, he never talks and doesn't hear anything were saying. bwahahaha!"
Will someone who actually uses voice confirm that this can be CLOSED because of the new viewer (1.18.1).
Mercia, there is still no linux support. Linden Lab has made very misleading announcements such as "Voice is open source" and "the grid is fully voice enabled"..
But those are wrong, there is no Voice Linux, and it's very much not open source. The initial question to this issue was : "
Any news on the progress of the Linux Voice Beta - Lindens please?" I cannot use voice . I keep getting : "2007-08-04T09:47:05Z WARNING: ll_apr_warn_status: APR: Connection refused". Tried opening up my router but to no avail. Skype works, but the voice for Second Life seems be a full VoIP service , which i don't have ( my subcriber-line does not support it ) . But that was not the issue and question.... so i think this I found this line in my terminal output :
2007-08-04T13:01:12Z INFO: LLVoiceClient::stateMachine: /mnt/sda1/SecondLife_i686_1_18_1_2/SLVoicenot found. Sorry .. :/ This is what I found in my terminal output:
2007-08-12T06:16:45Z INFO: LLVoiceClient::setState: entering state stateStart This last line was repeated over and over, one every second as you can see from the log times below. Note the line: /home/ethan/sl/SecondLife_i686_1_18_1_2/SLVoicenot found. After some time, I ran through the voice setup and selected OK, which dismissed the voice setup dialog. Here's the terminal output during that time: 2007-08-12T06:30:06Z WARNING: ll_apr_warn_status: APR: Connection refused After this I opened the Preferences menu and in the Voice Chat tab I unchecked the Enable Voice Chat box. Here is the terminal output: 2007-08-12T06:30:13Z WARNING: ll_apr_warn_status: APR: Connection refused After this there were no more warning messages. So it appears that the reason voice isn't working is due to a missing file called SLVoice. I'm guessing that this is that "binary blob" that Vivox was supposed to have provided, but hasn't. Can anybody confirm this? Vivox says they are waiting on Linden Labs, but this is obviously not true, since we now have the viewer, it has all the functionality in place for voice, yet it doesn't work because it cannot connect to the daemon which Vivox has not provided. The ball is in Vivox's court. Also, is anybody from Linden Labs taking any action on this? Obviously LL pays Vivox for this service, and if Vivox isn't doing their job, they need to be dealt with. To all ,
About the voice-support announcement for Linux : https://wiki.secondlife.com/wiki/SLDev-Traffic_23#Apologies.2C_and_Voice_for_Linux About the usability of Linux-client combined with SLVoice.exe and WINE : Regards, WiLLuMPJuH Just to let you guys know, short answer, this is hopefully coming soon. We've had recent internal discussion and haven't forgotten about it.
I personally think that Linden Labs saying that "SecondLife is now fully voice enabled" is just a lie. It can't be fully enabled if not all clients can use it.
Sometimes I also think if wouldn't it be better to stick to free and open source software when enabling voice. Changed priority to match internally – not because it isn't important to us, but because this isn't a Critical problem in the way that content loss or frequent crashing would be.
I'll ask Tofu Linden for our latest status on this. I'm pleased to report that we have a Voice-enabled Linux viewer limping along internally now; I expect that it will hit a release at the soonest moment that the voice support reaches a basic level of stability.
This is not a "new feature", since the whole of SL is now supposed to be voice enabled. Its a bug affecting one platform, and the bug is that the voice feature isn't working. I have the option to enable voice in my client, but it doesn't work (because there is no code to support it, I guess).
I am sad to see that voice seems to stay vaporware for me and all other GNU/Linux users. I would have preferred we never got voice, but now its here, I want to be able to join in like everyone else. I pitty the suit that decided to go first view on only two platforms, and even more the one that didn't care if voice was free software/open source software. Thanks to those of you that do work on it, it would be nice with an update though. Goldvald, I think Linux is still alpha software (the equivalent of beta on OSX or Windows), so voice works on the officially supported OSes, and remember Vista is not officially supported (and voice did not work on it for me). At least there is a Linux Voice Viewer that allows the setting of Voice for our parcels.
PS, I use Linux 95% of my SL time, 4.9% OSX 0.1% Vista Mercia To Tofu Linden - whats the progress with the Linux Voice Enabled SL Client going?
Any news yet? Testing to see if tofu's messages come through (ignore this)
Mercia, regarding the Linux viewer being "alpha", that's not the same as being "unofficial". Notice that there are (normally) three downloads available whenever a new viewer is released - Windows, Mac, and Linux. These are the three official platforms for SL, and it's unfortunate that the Linux viewer seems to be put on the back burner so often. The Linux viewer is the most stable of all three, so it's amazing that it's called alpha!
Still anxiously awaiting any news on this issue. Corax, I wrote "offically supported" not just "Offical", even Vista is not entirely offically supported (unless I misunderstood the last blog about it). As I understand it the offically supported platforms are Windows XP/2000 and OSX Panther/Tiger. But I may be mistaken. If an OS is not "offcially supported" LLs can chose to not fix a problem, just attend a triage meeting when a Vista bug is discussed and you will discover that that is an option, but usually the bugs are addressed (as are Linux ones)
You ask why it is alpha software, probably because once something is called beta then Linux users expect it to work as good as release software on OSX or Windows. Its to do with the naming conventions in the different OSes, and the fact that some great Linux software was beta for a long time after it was very stable indeed - remember Firefox before it hit 1.0? I was using it (more accurately using Mozilla) from the time is was first released and it was stable for me from the outset. Mercia Another Linux version of the software came out, but the voice is still not operable on my system. Any update on this issue?
Linux voice support is improving but not yet in a state where it would typically cause less frustration than joy.
If you need help on getting voice to work for linux, don't you have a location where the current code can be viewed and worked on by those who care to include this feature? If the code to support voice on linux is still in the petri dish, please consider allowing allowing visitors to take a look under that microscope.
They can't do that, the code for voice is closed source and isn't owned by Linden Lab. Quality proprietary software at its finest (i.e. never working right).
Gigs Taggart - If Linden Labs is working on the Vivox blob, I can understand why it is being worked on behind closed doors. If it is just the Secondlife Client, we don't need to look at the vivox blob code. We just need to look at how the linux client can make use of vivox's protocols (unless of course it violates the agreement made between Linden Labs and vivox when they included vivox's binary with their open source client)
protocol != source code. Why aren't they letting the linux community help tackle this problem and fix this issue sooner? Where do the ip roadblocks lay? 0_o? ilobmirt:
We have the specs from Vivox released under a permissive license, and the code for the SL viewer side of it is already released. Nothing is stopping anyone from implementing a Free vivox client. If you think you are up to it lets do it! Theoretically, a non-vivox technology may work, if all the grid servers do is send data that tells how far away an avatar is from another for the distance effect, downside, non-vivox users cant talk to vivox users. plus, someone would need to host a server that the clients talk to for voice.
Also, do not say skype for VOIP, it just wont work, it doesnt work the same way, closed protocol, and chances are, even if skype somehow made it work, it probably wouldnt be on the same set of services the regular voice is on. I was looking more in the direction of technologies like mumble/murmur, which act like ventrilo/teamspeak, which is what SL voice seems to act like. I dunno the details on that. however, this isnt really a solution, but maybe a consideration if the SL devs want to move to a fully opensource solution in the future if there's ever a falling out with vivox. http://mumble.sourceforge.net/ murmur being the server side. Another thought would be trying to use wine to quickly hack the binary blob in, like using libwine, but then again, that's vivox' call. otherwise, keep trying with a wine wrapper until wine supports SLvoice.exe for the meantime. even then there's no guarantee that it'll stay stable. I'm not talking about a "non-vivox" client. I'm talking about rewriting the vivox client to be open source.
Gigs Taggart - Is the Linux vivox client that the Lindens are working on the 1.18.4.1 Release Candidate viewer available for download?
As of Yesterday, I followed https://jira.secondlife.com/browse/VWR-2041 I don't see the code of this client listed in https://wiki.secondlife.com/wiki/Source_archive Ps. Is it that, or is it that you all are working on ./SLVoice, which wasn't included with the release candidate download? Is that available for compilation (granted legal issues have already been taken out)? If so, where is the link? No one is working on anything yet that I know of, but yes, I'm proposing completely replacing SLVoice.exe with an open source code base.
Update ! Update ! The SLVoice for Linux with Wine solution is working for me ! Had a succesful session at an infohub and although scrambled i was heard and answered too. Even heard 2 persons speak at once.
Neccesities :
No need to patch or recompile SL Linux client. Patch is applied. Start SLVoice.exe with parameters : -p tcp -i 127.0.0.1:44124 It takes a while and can get tedious to get a connected session to the SIP-servers of VIvox. It is in my case always neccesary to manually control the logon-sessions for voice. Disable Voice in SL. Restart SLVoice.exe ( SLVoiceAgent will keep running ) and re-enable Voice in SL ( CTRL+P). Part from a succesful session 2007-11-13T13:39:32Z INFO: LLVoiceClient::setState: entering state stateDaemonLaunched Stuck with error-messages tho ..
Don't expect fluid quality. But I could hear others and was heard. Itz wheely wheelvy vurks ! Woohoo .. XD as WiLLuMPJuH Gausman posted.
it seems to works, connects etc, altho, i teleported to quit a amount of sims, and found no one voice enabled, no voice enabled friends at this time either. so, one it makes you live in ur own voice world ? or i just have very bad luck finding some one voice enabled. Well, it's been more than a month since there has been any official statement from LL or Vivox as far as I can tell. The last such post seemed to say that the official Linux Voice Client was just around the corner. Is there any new news?
I'd love for them to at LEAST (Big keyword here) give us the code to their linux vivox client. I wouldn't care whether or not the component to the linux client is finished, it should be visible for editing from the linux community.
quote Tofu Linden - This is proof enough that they got something that works instead of the WINE + Windows Binary we have been used to. Why isn't it that I cant find this internal solution available as source? If we put our time into developing our own vivox module for linux, it might have been wasted time because the one developed by Linden Labs has been finished. And when there are two different solutions to the same problem, the way it works is this. One solution gets put in, or there gets to be a lengthy period of time where code from both become the new vivox module. Now I know that diversity for the same issue can be good in the open source world, but I doubt that we shouldn't be on the same page when it comes to working on the vivox module. Show us the code, or as kindly suggested by JamesReese Eddy, don't tie yourself to proprietary services "...as kindly suggested by JamesReese Eddy, don't tie yourself to proprietary services" -ilobmirt tenk
Let me clarify, I did not suggest that. Although I would love to see LL abandon Vivox in pursuit of an Open Source solution, such as Mumble, I realize that that is a thing of the distant future, at this point. For the time being, Vivox is the solution, they have no intention of opening the source code. They, initially tried to get away with leaving Linux out of Voice all together. We saw to it that they would not get away with that. Now both LL and Vivox are not giving us any progress reports. I just would like some news on when we can expect it to be ready for us to start using it. I really think that pressuring them to release the source code is a bad idea: they are not going to do it. Therefore, it only serves to make Vivox defensive and reluctant to provide and support the Linux client. Are we on the same page James?
There is no way we can pressure vivox to open their blob. Neither us, nor Linden Labs can force this upon vivox. Its up for Vivox to open up their stuff. (Again, I doubt that will happen) But If I am right, I hear that Linden labs has a module under development that will be the linux version of the Secondlife voice modules that are out for Mac and Windows. Am I wrong to say that Linden Labs has not let us see this Linux native module? What I have asked Linden Labs before, was if their Linux native in-house module had proprietary code in it. If The code is clean and completely from within its own development pool, why isn't there at least a link to this code that I know of? That is all I ask, a simple http or ftp link to Linden Lab's in house module that is supposed to wrap around vivox's Linux blob. If that is not possible, I'd like to know why Linden Labs can't release its own code, its own ip. If Linden Labs wont bother to release their own code, are we going to bother making our own vivox blob wrapper? Will Linden Labs even take our module? We (Linden Lab) don't have the source for the voice SDKs - they are opaque to us. The wrapper code with which we 'speak' to the SDK is already part of every Linux build and source release, and had been for a long time.
Here's a status update I posted to the forums:
"There's nothing particularly new to report - we're re-iterating once again with the voice SDK vendor now that we have feedback from a round of internal testing. "I'm still convinced that releasing what we have right now will cause more frustration than happiness to the average Linux user, but having waited so long now I'm strongly inclined to release the next SDK iteration anyway, assuming no regressions from the current version." Thanks Tofu, that is music to my ears. I am pretty sure most people understand that it will be more frustrating and buggy, at first. But at least we will have something, and we can choose whether to use it or not. I can only hope that Vivox will take our bug reports to hart, and that the realize how much we will be able to contribute to the project.
Yes, ilobmirt, I think I misunderstood you. We do seem to be on the same page. I suppose I would also say if you are going to "tie yourself to proprietary services", don't do so with a firm that, after at least 10 months, can only get their pre-existing technology 2/3 the way to full implementation.
Tofu,
Thanks for the update. I would love to give the voice enabled client a try ... But I will make sure that I always have a stable client which I can fallback on. (Or the WindLight, this is awesome!) Regards, Thanks Tofu for the update, if you need a tester just give me a shout.
Tofu,
Isn't it the case the we linux users only need an SLvoice executable? Linux Voice support is in QA right now. It might miss the 1.19.0 boat, but should arrive subsequently.
YAY!!!!!
I've been experimenting with running SL under wine, and it mostly works.. But native would be really nice! Progress report for fedora core 8.
Updated with yum and an wine update came tried to get voice working again. Voice via wine is working with OSS and pluls audio. In winecfg do not select anything other than OSS. Run as usual. The voice choppyness is gone. Finaly wine voice under linux and wine. Just tried Windlight Linux version SecondLife_i686_1_19_0_79185_WINDLIGHT and guess what? Voice is enabled and worked!
No modification - no use of wine - just un-tared the tarball and ran the binary! Running on Fedora Core 6 - I'll try it on a more recent version of Fedora and post the results later. Still not supported in the "Standard" beta client. The WindLight 1.19rc viewer works great with Voice in my Ubuntu 7.10 32bits.
Some is missing though in my Fedora8 and ArchLinux that makes it break. It seems that exactly at the time that the Active Speakers list should be populated LLVoice stops and starts it self again. ie: If I'm walking around all alone without anyone around with Voice, I can consistently see myself in the Speakers List. As soon as I get near someone that has voice, and the list is going to get updated, LLVoice restarts, that means, the list goes blank and in a while my name comes back to the list. This doesn't look sound related at all. Any ideas? Missing libraries? Just downloaded last windlight client, and it works... some performance issues, but im not sure if they are related to my internet connection or the other peopel connections... But I can talk, hear and be heard!!! ;D
Thanks Tofu for releasing it. Im happy, will work later on improving performance and giving a more accourate feedback! (PS: Ubuntu 7.10) Not a distro issue for me. Just figured that Ubuntu 7.10, fresh, no updates, from the original CD, works, even in LiveCD boot, with my desktop, and not my notebook.
So, as I see... it works with a onboard snd_intel8x0 (AC97) in my desktop (Abit motherboard) and NOT with my hda_intel in my Dell 131L notebook. Can someone tell me why a kernel module sound driver break LLVoice? Royer, can you attach your SeconfLife.log file from when it fails with the sound driver? Thanks.
I dont see any errors, but here it goes.
This is a level 5 debug of LLVoice that I did a couple of days ago....
I try to use voice with newest windlight using Kubuntu 6.06 (Dapper Drake). The sliders are there, but it didn't work. During configuring voice I didn't hear anything while speaking into the microphone.
This bug is now fixed, please open up specific issues in new bugs.
Comet Bumbo: You aren't supposed to hear anything when you talk, that would cause feedback. We still have the same problems with voice, why is this closed?
http://jira.secondlife.com/browse/VWR-1994 We need to be able to HEAR, so we aren't now missing important events and meetings... that's a show stoper. Now to talk, that would be a second step, which I personally don't care about. I even bought a BT headset to try to resolve this and got deeper and deeper into more obstacles.... no docs for OpenAL, everything so misterious.... HELP! VWR-1994 relates to this, and would help as a first step: being able to LISTEN only, without OpenAL trying to open the INPUT source, which is probably why it breaks Voice for non-full-duplex hardware mixers sound chips.
TOFU released a client version once that worked with GNU/Linux. It wasn't terribly stable, but at least it enabled you to know what was going on around you. Now voice doesn't work anymore for GNU/Linux users.
The lack of support for voice on GNU/Linux, is increasingly annoying, since many events and social groups exclusively communicate using voice. It has driven me to a point, where I feel that if it wont be fixed soon, I would rather see voice removed on SL, because its ruining the expirience for both me and a lot of other users. I'm aware that Linden Lab has no obligation to sattiesfy all users, but I'm very disappointed in the lack of service with this issue. If I am wrong, and you are working hard to fix this, and we can help in any way, please tell me what info we need to collect for you. "Voice isn't working" isn't terribly useful, I guess. Then again, I guess if Linden Lab tests the clients, you're aware that voice is broken on GNU/Linux, and hopefully already working on it. A status, and maybe some pointers so we help you fix it, if voice code is Free Software and/or open source. (Details of your findings will probably be most helpful, and where to send patches) I appreciate the concern, but re-opening this issue is not the way forward (even if voice were broken for everyone - which it isn't). Please file or note specific issues.
We're still working to improve general compatibility. A First-Look with a much newer Voice SDK should be available soon. Tofu: I asked in the Linux Client group. Apparently voice is broken for everyone, at least if we talk about voice in Public chat. I had one person claim that voice in IM sometimes worked for them, but we were unable to reproduce this.
The fact seems to be that voice simply doesn't work at al,l for GNU/Linux clients right now. You say that reopening this bug isn't the way forward, and you ask for details. I am not sure which details we can provide, but I assume you want us to open a new bug with these details. Exactly what details would be helpful to provide? From a users point of view, I get a white dot over my head, and nobody else does. From other peoples point of view, all that have working voice gets a dot over their head, which excludes me. I've been able to see dots next to nicks in a conference, but no sound came, even though the dots were flashing. In public however, voice simply doesn't do anything. Please tell us how we can help you and ourselves. What would a good title for a new bug be, and what kind of details would you like us to provide, and how do we gather data that can help find the way forward? And thank you for originally fixing this issue, it was a great relief, and I guess thats why many of us are disappointed that the problem now has returned. Goldvald, for me voice isn't broken. I can not use it with my laptops hda_intel soundcard, but works perfect with usb headset. I switched recently from ubuntu to debian, this caused some issues related to faulty cpu detection of libvivox with the kernel, how to fix this i found in the jira, too. Apparently its broken for some soundcards and some kernels.
Details could be: if collected this information can help structure which issue is related to which component, for avoiding jiras about "voice not working on distro x" when indeed it should be named "voice not working with soundcard y" Pulseaudio, which is default in ubuntu now, can cause all of the above problems. Ubuntu made a serious mistake pushing pulseaudio out the door when it wasn't ready.
Gigs Taggart, we are not talking about configuration problems here, these are BUGs.
I have contributed whatever logs I was asked for, but never got ANY feedback about the problem with low-end sound chips. Voice improved, started working for some chipsets... and should continue to make progress. It doesn't make sense to close this ticket because it works now on SOME sound chips. BTW, if OpenAL/Vivox/LLVoice or whatever would give us an option of configuring it's details, and configure it to USE PULSEAUDIO, Voice would already be working and any bugs would be quickly corrected by the OpenSource comunity. I see this Vivox/OpenAL thing as ObscureSource (nothing to do with you, Opensource Obscure! rsrs). Well, all that is probably true, but this isn't the issue to do it in, this issue was asking for initial voice support, which has been provided.
Here is a response from the "second life support":
http://forums.secondlife.com/showpost.php?p=2154481&postcount=15 Sooo... how long do we have to wait until voice truly works? Funny and very sad. Basically it is like this because 90% doesn't acutally need support, need learning. The ones that really need support don't get. But you know where that comes from...
I bet 2 days between an SLVoice developer and a couple dedicated volunteers would break this down to what the real problem is... and with that.... all others would make it work. I guess someone should make a bugreport to make the voice part of SL free software or open source.
Then again, that would probably be considered a policy change ... wait .. isn't the policy of LInden Lab already to release sources??? Goldvald, Linden Labs does not own the source code to the voice system, Vivox does. Therefore, I'm afraid that Linden's policy is irrelevant. Vivox has made it very clear that they will never release the source code.
That's not true, they said they will open source it eventually, but they haven't really made much movement toward actually doing it.
Well, I guess that is not going to happen soon then, so what are the alternate options?
Here are some I can think of offhand: 1. Try to make some compatible library thing for GNU/Linux, so the code works without pulseaudio and investigate how we can help the Lindens help Vivox fix the problem. (If I understand it correctly?) 2. Code a completely alternate (and probably incombatible) voice system for GNU/Linux. 3. Reverse engineer(1) the proprietary code, and make a free version that works and rocks! I think 1 and 2 is going to be either hard or not really worth the trouble. I can see how coding a new and better voice system would be nice, but I bet it would be hard to get Linden to skip the existing code. That would leave us being able to chat only with our geek friends and whoever else we could pursuade to run it. The Lindens have done a great job reducing the crashes and improving the stability of the client, but when it comes to voice, things seems to move slow. Someone might suspect that Vivox could be the reason for this. So maybe the best way to go is to prune the sick branch? What are our odds, and what needs to be done? Reverse engineer may sound a little crazy at first to some, but for GNU/Linux, ICQ support, a lot of hardware support and other stuff was made this way, and as far as I know, they're also trying to make a free alternative for flash, so why not SL-voice on GNU/Linux? So, what are the chances of reverse enginering their code and make a free version? I think they use (at least partly) a SIP protocol, and I would assume they use more or less standard codecs for the actual voice transmission. I don't think I could handle such a project alone, I would probably have too little time on my hands, but it would be fun trying, and chipping in whatever resources I could spare! This seems to be the GNU/Linux way (if there is a such). (1) (At least in some countries its legal to reverse engineer code). Any news on the ETA of that "First-Look with a much newer Voice SDK" that Tofu mentioned last month?
It's still iterating through QA. That's the final hurdle for this branch (I think) but I don't know of an ETA yet.
I would like to mention that i got Voice on Linux running. You have to get rid of the alsa-driver, and install the new oss4 from 4-Tech (http://www.opensound.com/
There is no voice support for AMD64, x86_64. Should this bug be reopened?
@Techwolf
Second Life clients doesn't support 64-bit at all, to my knowledge. If you like, you can report this as a bug. I run 64-bit myself. However, you can run the client using 32-bit libs. I do this myself, and yesterday I managed to get voice working. I had to do the followering, which kinda breaks other stuff, but I am sick of being "deaf": remove the package "pulseaudio" disable pulseaudio (go into "system->preferences->sound" and set it all to alsa). Reboot the machine (thats what I did) .. or relog (don't know if thats enough). When you start up the second life client, you may have fiddle some with device settings before it works. There doesn't seem to be much logic in my case, hopefully there is in yours. However, try choises with "alsa" first. In some cases it still wont work, either because you lack some 32-bit libraries or because your hardware is not supported under GNU/Linux. I believe this unfortunately is true for the popular "soundblaster live" card, for instance. Good luck! Thanks for a comment in the Linux group I went and installed OSS4. Finally have voice working! All sounds and voice working!
I have Ubuntu 8.10 latest updates, 32 bits, and an ATI IXP AC97 sound chip on the motherboard of an HP desktop. I just installed OSS4, from http://www.opensound.com Tips: gotta hava devel packages, because the instalation compiles OSS4 modules that will load in place of the old OSS. Thats why you have to reboot it also. This should do it. I also disabled the pulseaudio services since I'm not using them anymore. Hope that helps! Great with options, right? I haven't tried OSS4, but its nice to know that this will work on 32-bit (and possibly on 64-bit, I guess).
I actually got voice working with the SLim first look viewer. I'm on Ubuntu 8.10, I am 64bit, and I reinstalled pulseaudio! I have an onboard soundcard, and I have a USB-headset (FATAL1TY from Creative). Voice goes in the headset, and I can both talk and listen. Sounds go out through my stereo, which my onboard soundcard is connected to. The only problem I had, was when I try to send the voice out the speakers, but I guess I haven't tried a lot. I am very happy with this, and it looks like we're going to have voice with 1.23 of the client, if the code from the first look viewer is going there. Now we just need the voice part to be free software! Please tell Vivox to hurry! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||