26 May
2006
26 May
'06
8:06 a.m.
Greetings;
Since I can't get any of the common VoIP things to work due to a lack of
duplex function in my lappy's chipset, and my inability to convince the
person bugtrack assigned to my bugzilla entry that its not my fault, I
thought I'd try zfone next.
Unforch, the first step, ./configure, fails with 2 stanza's of this:
checking linux/byteorder/little_endian.h usability... no
checking linux/byteorder/little_endian.h presence... yes
configure: WARNING: linux/byteorder/little_endian.h: present but cannot
be compiled
configure: WARNING: linux/byteorder/little_endian.h: check for
missing prerequisite headers?
configure: WARNING: linux/byteorder/little_endian.h: see the Autoconf
documentation
configure: WARNING: linux/byteorder/little_endian.h: section
"Present But Cannot Be Compiled"
configure: WARNING: linux/byteorder/little_endian.h: proceeding with the
preprocessor's result
configure: WARNING: linux/byteorder/little_endian.h: in the future, the
compiler will take precedence
configure: WARNING: ## ------------------------------------------ ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
configure: WARNING: ## ------------------------------------------ ##
checking for linux/byteorder/little_endian.h... yes
checking linux/byteorder/big_endian.h usability... no
checking linux/byteorder/big_endian.h presence... yes
configure: WARNING: linux/byteorder/big_endian.h: present but cannot be
compiled
configure: WARNING: linux/byteorder/big_endian.h: check for missing
prerequisite headers?
configure: WARNING: linux/byteorder/big_endian.h: see the Autoconf
documentation
configure: WARNING: linux/byteorder/big_endian.h: section "Present
But Cannot Be Compiled"
configure: WARNING: linux/byteorder/big_endian.h: proceeding with the
preprocessor's result
configure: WARNING: linux/byteorder/big_endian.h: in the future, the
compiler will take precedence
configure: WARNING: ## ------------------------------------------ ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
configure: WARNING: ## ------------------------------------------ ##
checking for linux/byteorder/big_endian.h... yes
I've googled in vain for a solution as the make also fails later:
gcc -DHAVE_CONFIG_H -I. -I. -I../config -I../include -I../bnlib/
-I../srtp/include -I../srtp/crypto/include -Wno-unused -g -O2 -c -o
base32.o `test -f './base32.c' || echo './'`./base32.c
In file included from ../srtp/crypto/include/datatypes.h:60,
from ../srtp/crypto/include/err.h:49,
from ../srtp/crypto/include/rand_source.h:49,
from ../srtp/crypto/include/crypto_kernel.h:49,
from ../srtp/include/srtp.h:53,
from ../include/zrtp_protocol.h:13,
from ../include/zrtp_types.h:184,
from ./base32.c:7:
/usr/include/netinet/in.h:354: error: expected declaration specifiers or
‘...’ before ‘(’ token
/usr/include/netinet/in.h:354: error: expected ‘)’ before ‘?’ token
/usr/include/netinet/in.h:355: error: expected declaration specifiers or
‘...’ before ‘(’ token
/usr/include/netinet/in.h:355: error: expected ‘)’ before ‘?’ token
/usr/include/netinet/in.h:357: error: expected declaration specifiers or
‘...’ before ‘(’ token
/usr/include/netinet/in.h:357: error: expected ‘)’ before ‘?’ token
/usr/include/netinet/in.h:359: error: expected declaration specifiers or
‘...’ before ‘(’ token
/usr/include/netinet/in.h:359: error: expected ‘)’ before ‘?’ token
./base32.c: In function ‘b2a’:
./base32.c:59: warning: comparison of distinct pointer types lacks a cast
make[1]: *** [base32.o] Error 1
make[1]: Leaving directory `/usr/src/Zfone/libzrtp-0.2.0/src'
make: *** [all-recursive] Error 1
This is after outputting dozens of warnings about 'too many arguments
for function'
Phil Zimmerman's code is usually of quite high quality...
--
Cheers, Gene
26 May
26 May
10:27 a.m.
Gene Heskett wrote:
Greetings;
Since I can't get any of the common VoIP things to work due to a lack of
duplex function in my lappy's chipset, and my inability to convince the
person bugtrack assigned to my bugzilla entry that its not my fault, I
thought I'd try zfone next.
Unforch, the first step, ./configure, fails with 2 stanza's of this:
checking linux/byteorder/little_endian.h usability... no
checking linux/byteorder/little_endian.h presence... yes
configure: WARNING: linux/byteorder/little_endian.h: present but cannot
be compiled
Is this a device driver or a user space program.
Basically no user space program other than libc should be using
kernel header files.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
`[Microsoft] are in the business of giving customers exactly what they ask
for, which sounds like a nice idea until you realize that most Microsoft
customers are idiots.' --- Eugene O'Neil on comp.os.linux.development.system
11:56 a.m.
Erik de Castro Lopo wrote:
Gene Heskett wrote:
I don't have a real good understanding of it, but I believe this wedges
itself between the VoIP app, and the drivers.
That file appears to exist on this box in the usual location, and in the
kernel src trees:
root@diablo libzrtp-0.2.0]# locate big_endian.h
/usr/include/linux/byteorder/big_endian.h
/usr/src/kernels/2.6.16-1.2096_FC5-i686/include/linux/byteorder/big_endian.h
/usr/src/kernels/2.6.16-1.2111_FC5-i686/include/linux/byteorder/big_endian.h
/usr/src/kernels/2.6.16-1.2118_FC5-i686/include/linux/byteorder/big_endian.h
/usr/src/kernels/2.6.16-1.2122_FC5-i686/include/linux/byteorder/big_endian.h
In going thru the config.log, the path it used was
/usr/include/linux/byteorder, and there doesn't seem to be any reference
to a 'uname -r' to determine the path to the includes, so this doesn't
appear to be a valid conclusion on your part that it was using kernel
headers.
However, I'd also note that the kernel versions of these *endian files
are both over a kilobyte larger and several years newer. As this is an
up 2 date, from scratch FC5 install, I was surprised to see files dated
2001 in the /usr/includes tree.
--
Cheers, Gene
Greetings;
Since I can't get any of the common VoIP things to work due to a lack of
duplex function in my lappy's chipset, and my inability to convince the
person bugtrack assigned to my bugzilla entry that its not my fault, I
thought I'd try zfone next.
Unforch, the first step, ./configure, fails with 2 stanza's of this:
checking linux/byteorder/little_endian.h usability... no
checking linux/byteorder/little_endian.h presence... yes
configure: WARNING: linux/byteorder/little_endian.h: present but cannot
be compiled
Is this a device driver or a user space program.
Basically no user space program other than libc should be using
kernel header files.
Erik 
3:31 p.m.
On Fri, 2006-05-26 at 05:05 -0500, Gene Heskett wrote:
Greetings;
Since I can't get any of the common VoIP things to work due to a lack of
duplex function in my lappy's chipset, and my inability to convince the
person bugtrack assigned to my bugzilla entry that its not my fault, I
thought I'd try zfone next.
Um, you never answered tiwai's last question.
"Grr, you make the things too complex. Let's sort out the thing
straight.
The duplex problem and the inproper recording are different things.
First, check whether both non-duplex playback and recording work
properly.
For checking playback, you can use speaker-test program in alsa-utils
package, too. Run "speaker-test -c2 -tw", for example.
As I mentioned, you can test recording of the played stream by setting
"Capture Source" to "Mix". It needs no extra hardware setup, so no
hard
work after running a full marathon.
If the full-duplex works by this way, skype and other programs should
work as well -- as long as you set up the mixer correctly.
Anyway, don't use audacity or whatever apps might be using OSS emulation
for tests. They can't be used as references. Use basic tools included
in ALSA packages for primary tests."
We have to debug one thing at a time, and using the simplest possible
tools, rather than some huge VOIP app that goes through the OSS layer.
If you are not interested in debugging it further I will close the
report.
Lee
10:06 p.m.
Lee Revell wrote:
On Fri, 2006-05-26 at 05:05 -0500, Gene Heskett
wrote:
So I'll repeat that last reply, which may not have ended up where it
should have,
but this is a little more public.
Greetings;
Since I can't get any of the common VoIP things to work due to a lack of
duplex function in my lappy's chipset, and my inability to convince the
person bugtrack assigned to my bugzilla entry that its not my fault, I
thought I'd try zfone next.
Um, you never answered tiwai's last question. "Grr, you make the things too complex. Let's
sort out the thing
straight.
The duplex problem and the inproper recording are different things.
First, check whether both non-duplex playback and recording work
properly.
For checking playback, you can use speaker-test program in alsa-utils
package, too. Run "speaker-test -c2 -tw", for example.
This works, PROVIDED its the last thing started. If started before the
arecord or audacity recording, then arecord and audacity are denied
access to the device.
However if audicity making a recording is started first, then the
recording works fine and the speaker-test also works fine.
If audacity's recording is stopped while speaker-test is running, then
speaker-test grabs it all and audacity is once again locked out of
accessing the device.
As I mentioned, you can test recording of the played
stream by setting
"Capture Source" to "Mix". It needs no extra hardware setup, so no
hard
work after running a full marathon.
Capture source in this case and in the above tests is the bottom of the
slider, red 'led' in kmix, and it was set to mic.
If the full-duplex works by this way, skype and other
programs should
work as well -- as long as you set up the mixer correctly.
As shown above, it doesn't unless things are started in a specific
order, which in the case of skype at least, I have zero control over. I
assume because it opens the two paths to the device in the wrong order
or something.
The bottom line is that skype|ekiga, neither one works in that I cannot
hear the other party, while I am crystal clear to the other party.
I'm aware that the tests seem to indicate the reverse is true, but the
errors reported in the case of starting speaker-test, and then running
audacity, are different.
As far as doing a recording using arecord, from the example in the manpage:
[root@diablo ~]# arecord -d 10 -f cd -t wav -D copy foobar.wav
ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM copy
arecord: main:547: audio open error: No such file or directory
This is while speaker-test is running. But stopping it does not change
anything:
[root@diablo ~]# arecord -d 30 -f cd -t wav -D copy foobar.wav
ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM copy
arecord: main:547: audio open error: No such file or directory
So obviously there is something fubar in that command line. With it
stopped, audacity can record ok, but cannot simultaniously playback
either the track just made, or a different one, exhibiting the same
symptoms as skype/ekiga, but actually worse in that the playback
obviously falls way behind itself.
Anyway, don't use audacity or whatever apps might be using OSS emulation
for tests. They can't be used as references. Use basic tools included
in ALSA packages for primary tests."
I was not aware that audacity was an OSS aplication.
We have to debug one thing at a time, and using the
simplest possible
tools, rather than some huge VOIP app that goes through the OSS layer.
If you are not interested in debugging it further I
will close the
report.
Oh I'm interested, but busier than that famous cat on a tin roof since
wednesday morning, when we used the biggest crane I've ever seen up
close (and it could have been 6 feet taller, but at 182 feet it was all
used up & we had to re-rig the lift) to pick a 6 bay superturnstile
antenna sized for US channel 8 broadcasting, out of the top of the tower
and laid all 55 feet and about 2.5 tons of it, in a pair of cradles I
made to hold it about 4 feet off the ground while I try and find
suitable 7/8" 50 ohm air semi rigid coax to repair 4 of the 24 such coax
lines on it that have been damaged by poor installation handling years
ago when it was moved to here, and 52 years exposure to the weather.
Pretty it ain't.
Now I'll have about 3 days to play as the majority of the suppliers of
such stuff are taking a long 3 day weekend off now, leaving me with only
the usual stuff to do.
--
Cheers, Gene
6557
days inactive
6557
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Erik de Castro Lopo -
Gene Heskett -
Lee Revell