Flow instead of port forwarding

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Flow instead of port forwarding

Roland Schwarz-2
Dear All!

Recently I discovered that I could not contact several repeater nodes
using qtel which can be connected by an echolink client with no issues.
Reading on the echolink website I discovered that there is a mode which
allows to traverse a NAT with the help of the directory server by
establishing what they call a "flow".

I fired up wireshark while connecting with qtel and discovered that qtel
is not even trying to contact the directory server on link setup phase.
Does this mean I do not yet understand the protocol enough or does it
mean echolib is not yet using this mode of call setup?

Thank you for help,
73 de Roland, oe1rsa


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

steve-k
Hi Roland,

are you really sure that the reason for connection failure is the
IP address update from the directory server ?
SvxLink has a problem with NAT, when UDP source port oriented
packet routing is used. You can identify  this problem by checking the
source port of the transmitted UDP packets leaving your router.
This might be a problem if your router does not run Linux.
The source port of outgoing UDP packets identify which LAN
computer has sent the packet and hence redirect received packets
sent to the source port back to the LAN computer. This is a SvxLink server
related problem and only affects responses on incoming connections.
You'll need port forwarding for incoming connections requests anyway.
Please let me know if this is the experienced problem.

73s Steve, DH1DM


----- Original Nachricht ----
Von:     Roland Schwarz <[hidden email]>
An:      Discussions about development issues <[hidden email]>
Datum:   24.03.2014 13:01
Betreff: [Svxlink-devel] Flow instead of port forwarding

> Dear All!
>
> Recently I discovered that I could not contact several repeater nodes
> using qtel which can be connected by an echolink client with no issues.
> Reading on the echolink website I discovered that there is a mode which
> allows to traverse a NAT with the help of the directory server by
> establishing what they call a "flow".
>
> I fired up wireshark while connecting with qtel and discovered that qtel
> is not even trying to contact the directory server on link setup phase.
> Does this mean I do not yet understand the protocol enough or does it
> mean echolib is not yet using this mode of call setup?
>
> Thank you for help,
> 73 de Roland, oe1rsa
>
>
> ----------------------------------------------------------------------------
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Tobias Blomberg
In reply to this post by Roland Schwarz-2
On Monday 24 March 2014 13:01:22 Roland Schwarz wrote:

> Dear All!
>
> Recently I discovered that I could not contact several repeater nodes
> using qtel which can be connected by an echolink client with no issues.
> Reading on the echolink website I discovered that there is a mode which
> allows to traverse a NAT with the help of the directory server by
> establishing what they call a "flow".
>
> I fired up wireshark while connecting with qtel and discovered that qtel
> is not even trying to contact the directory server on link setup phase.
> Does this mean I do not yet understand the protocol enough or does it
> mean echolib is not yet using this mode of call setup?

In the EchoLink FAQ this is what they say:

"There are two parts to it. The first is simple; the program now uses the same
ports (5198 and 5199) for both source and destination when it sends UDP
packets. Prior to this, it used dynamically-assigned source port numbers. Most
types of NAT routers will establish a "flow" when they see a request and a
corresponding response with precisely reversed addresses (including port
number), allowing other unsolicited packets to be received over the same "flow"
within a certain time period. Using fixed source ports ensures that the source
and destination addresses are exactly swapped in a response packet. This also
avoids false triggering of denial-of-service protections built into some
firewalls, which had been a problem for a few users."

SvxLink have always used fixed source port numbers instead of dynamic ones so
one would think that this would already work in SvxLink. I have not done any
verification on this though.

"The second part is a way to accommodate a firewall on incoming connections.
When a node initiates a connection, it sends an additional packet to its
addressing server indicating that it wishes to connect to the other node. The
addressing server relays this request to the receiving node, which responds by
sending a pair of packets back to the initiating node to establish the "flow"
described above. (Nodes maintain a UDP "flow" with the addressing server to
prepare to receive these requests by sending packets to it periodically.) This
works even if the two nodes are on different addressing servers, because these
connection-request packets are relayed internally amongst the addressing
servers as well."

This is not implemented in EchoLib and so is not supported by Qtel nor
SvxLink. That is, there is no way for Qtel to tell the remote station to punch
a hole in the firewall for an incoming connection.

One can also read in the FAQ:

"Configuring port forwarding in your router is still recommended, if you have
access to it. This will ensure that you can connect to (and receive
connections from) any other node on the EchoLink network. Until port
forwarding is set up, you might notice that you can connect to some nodes, but
not others. The exact steps for configuring your router vary considerably from
one model to another; find yours in the list at portforward.com for specific
instructions."

So, it is still recommended to do a static configuration in the router.

Reference:

        http://www.echolink.org/firewall-friendly.htm

73's de SM0SVX / Tobias



>
> Thank you for help,
> 73 de Roland, oe1rsa


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Roland Schwarz-2
On 2014-03-24 18:44, wrote SM0SVX:
>
> This is not implemented in EchoLib and so is not supported by Qtel nor
> SvxLink. That is, there is no way for Qtel to tell the remote station to punch
> a hole in the firewall for an incoming connection.
>

Thank you. This is a very explicit and concise answer. I will try to
find out by contacting the operators of the respective nodes if they
configured explicit port forwarding.

Thank you,
and 73 Roland oe1rsa


--
_________________________________________
  _  _  | Roland Schwarz aka. speedsnail
 |_)(_  | sip:[hidden email]
 | \__) | mailto:[hidden email]
________| http://www.blackspace.at

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Rob Janssen
In reply to this post by Tobias Blomberg
SM0SVX wrote:

> "Configuring port forwarding in your router is still recommended, if you have
> access to it. This will ensure that you can connect to (and receive
> connections from) any other node on the EchoLink network. Until port
> forwarding is set up, you might notice that you can connect to some nodes, but
> not others. The exact steps for configuring your router vary considerably from
> one model to another; find yours in the list at portforward.com for specific
> instructions."
>
> So, it is still recommended to do a static configuration in the router.
>

My experience is that when you don't have a fixed mapping and the repeater you connect
via qtel is not very active, the connection is lost after a while.

This was not with NAT but with a similar config: a stateful firewall which allows incoming
traffic only when it matches outgoing traffic.  When there is no regular traffic, the "flow"
keeping the state (conntrack in Linux) times out, and when the repeater finally has some
audio to send it is rejected by the firewall.

The same will happen in a NAT router where no fixed portmapping is made.

So I had to permanently open ports 5198 and 5199 in my firewall, instead of relying on
the "-m state --state RELATED,ESTABLISHED -j ACCEPT" rule I have.

Rob

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Tobias Blomberg
On Monday 24 March 2014 20:20:50 Rob Janssen wrote:

> SM0SVX wrote:
> > "Configuring port forwarding in your router is still recommended, if you
> > have access to it. This will ensure that you can connect to (and receive
> > connections from) any other node on the EchoLink network. Until port
> > forwarding is set up, you might notice that you can connect to some
> > nodes, but not others. The exact steps for configuring your router vary
> > considerably from one model to another; find yours in the list at
> > portforward.com for specific instructions."
> >
> > So, it is still recommended to do a static configuration in the router.
>
> My experience is that when you don't have a fixed mapping and the repeater
> you connect via qtel is not very active, the connection is lost after a
> while.
>
> This was not with NAT but with a similar config: a stateful firewall which
> allows incoming traffic only when it matches outgoing traffic.  When there
> is no regular traffic, the "flow" keeping the state (conntrack in Linux)
> times out, and when the repeater finally has some audio to send it is
> rejected by the firewall.
>
> The same will happen in a NAT router where no fixed portmapping is made.
>
> So I had to permanently open ports 5198 and 5199 in my firewall, instead of
> relying on the "-m state --state RELATED,ESTABLISHED -j ACCEPT" rule I
> have.

Yes, this is what to expect. It will seem to work for short QSO:s but on idle
links the audio will not get through after a longer stretch of inactivity. The
link will seem to be up but no audio is getting through.

The thing causing this is that a connection to another EchoLink station
consists of two UDP ports, 5198 and 5199. One of the ports is used for control
messages and the other port is used for audio. On the control connection there
is constantly packets sent to indicate to the remote station that the link is
still up. The constant traffic on the control port will maintain the stateful
mapping in the firewall for that port. On the audio port nothing is sent unless
there is audio to send. This will make the stateful mapping in the firewall to
time out after a while. This will stop audio from coming in through the
firewall.

To open the firewall again, all that is needed is to transmit some audio and
the firewall will open up for incoming audio once again.

I don't know if the original EchoLink software do anything to maintain the
audio connection in the firewall by transmitting "keep alive" packets but I
know SvxLink/Qtel doesn't.

The only safe thing to do is to set up a static NAT configuration in the
firewall.

People that have been reporting problems connecting to some stations with
SvxLink/Qtel probably have no proper firewall configuration on one or the other
side. The reason it works with the original EchoLink client is due to the fact
that it has the ability to "punch a hole" in the remote firewall. SvxLink does
not have this implemented so this can explain why it will work under Windows
but not with SvxLink. As the EchoLink folks write themselves, they don't think
it's a good idea to use this automatic feature unless it's really necessary.
The limited use of this feature place it way down on the SvxLink TODO-list.

73's de SM0SVX / Tobias


>
> Rob


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Rob Janssen
SM0SVX wrote:

>
> People that have been reporting problems connecting to some stations with
> SvxLink/Qtel probably have no proper firewall configuration on one or the other
> side. The reason it works with the original EchoLink client is due to the fact
> that it has the ability to "punch a hole" in the remote firewall. SvxLink does
> not have this implemented so this can explain why it will work under Windows
> but not with SvxLink. As the EchoLink folks write themselves, they don't think
> it's a good idea to use this automatic feature unless it's really necessary.
> The limited use of this feature place it way down on the SvxLink TODO-list.
>

Probably this feature sends an empty packet every minute or so. Otherwise I would not
know what they mean by "punch a hole in the firewall".  Of course when there is regular
traffic, the firewall or NAT router will keep up the flow for a while.  In Linux the default for
this appears to be 3 minutes.  Such values are also often seen in NAT routers.

Of course, sending real data makes it keyup the transmitter.  So it would have to be
made certain that there can be packets that are discarded by the receiving end.  I would
think an empty UDP packet would be a good candidate for that.

Rob

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Roland Schwarz-2
In reply to this post by Tobias Blomberg
On 2014-03-24 18:44, wrote SM0SVX:
> So, it is still recommended to do a static configuration in the router.

Ok, yes. Sure. True, ähm :-(

The guys just seem to not do it, be it of inability or more likely
laziness. hi ;-) ...

What puzzles me more is that I am planning to set up a svxlink driven
node myself. Ok, yes I will be able to punch a hole through my firewall,
but when it comes to connect the repeater to others, I will suffer from
this problem despite my router is configured well.

Now, please don't get me wrong. I am not complaining in any way. I know
what free software is about, and you Tobias have done a great work.
Thank you!

I am considering to contribute instead and I am looking for a good
starting point, since the ability to connect to other nodes will be a
high priority on my wish list.

So please bear with me and allow to ask a few questions. (Yes I already
tried the mailing archives but was not successful so far.)

1) Are the echolink developers open to a native linux software, i.e. are
they willing to help with questions about the protocol, or are they
trying to hide information?

2) Is there any open documentation of the link protocol available? Will
I need to reverse engineer the protocol?

3) Do you think it is a good idea (besides what you have already told
me) to work on the "punch through the firewall" capability?

4) Are there prior attempts I should know about before starting?

5) Will this list be a good place to communicate about such a
development attempt?

6) How is sourceforge svxlink related to www.svxlink.net (if at all)?

7) Is the trunk of the svn repository at sf a good starting place?

8) Ah, and last but not least: Is it ok for you to work on this issue. I
know I could do it anyways, since it is GPL. But hey, I just prefer
doing things in consensus, since this considerably more fun.

tnx, vy 73 de Roland oe1rsa


--
_________________________________________
  _  _  | Roland Schwarz aka. speedsnail
 |_)(_  | sip:[hidden email]
 | \__) | mailto:[hidden email]
________| http://www.blackspace.at

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Tobias Blomberg
On Tuesday 25 March 2014 21:01:46 Roland Schwarz wrote:

> On 2014-03-24 18:44, wrote SM0SVX:
> > So, it is still recommended to do a static configuration in the router.
>
> Ok, yes. Sure. True, ähm :-(
>
> The guys just seem to not do it, be it of inability or more likely
> laziness. hi ;-) ...
>
> What puzzles me more is that I am planning to set up a svxlink driven
> node myself. Ok, yes I will be able to punch a hole through my firewall,
> but when it comes to connect the repeater to others, I will suffer from
> this problem despite my router is configured well.
>
> Now, please don't get me wrong. I am not complaining in any way. I know
> what free software is about, and you Tobias have done a great work.
> Thank you!
>
> I am considering to contribute instead and I am looking for a good
> starting point, since the ability to connect to other nodes will be a
> high priority on my wish list.
>
> So please bear with me and allow to ask a few questions. (Yes I already
> tried the mailing archives but was not successful so far.)
>
> 1) Are the echolink developers open to a native linux software, i.e. are
> they willing to help with questions about the protocol, or are they
> trying to hide information?

I don't think it's so much that they want to hide information (unless you
count the source code) but rather that they do not want to put in the time to
document the protocols involved.


> 2) Is there any open documentation of the link protocol available? Will
> I need to reverse engineer the protocol?

The protocols does not seem to be documented. I actually got help from
Jonathan/K1RFD himself to sort out the protocol when implementing the EchoLink
Proxy protocol. There were no documentation but I wrote it down here:

        http://svxlink.sourceforge.net/doc/echolink_proxy_protocol.html

What you should do if you want protocol information is to contact EchoLink
support and explain the situation. I'd try using the form at the bottom of
their support page:

        http://www.echolink.org/support.htm


> 3) Do you think it is a good idea (besides what you have already told
> me) to work on the "punch through the firewall" capability?

Since missing that feature seem to cause problems for some people it would be
good to have it implemented.


> 4) Are there prior attempts I should know about before starting?

None that I know of. There is some code in the "locationinfo" subdirectory
that is used to update the link status list on the EchoLink page. I don't know
if this same UDP "connection" is used to communicate the incoming connection
requests.


> 5) Will this list be a good place to communicate about such a
> development attempt?

Yes.


> 6) How is sourceforge svxlink related to www.svxlink.net (if at all)?

There is no relation. The official documentation for SvxLink is at
http://svxlink.sourceforge.net/.


> 7) Is the trunk of the svn repository at sf a good starting place?

Yes, that is the latest available code.


> 8) Ah, and last but not least: Is it ok for you to work on this issue. I
> know I could do it anyways, since it is GPL. But hey, I just prefer
> doing things in consensus, since this considerably more fun.

You are welcome to give it a try. Just read the "Contributing Code"
documentation first:

https://sourceforge.net/apps/trac/svxlink/wiki/Contributing#Contributingcode

73's de SM0SVX / Tobias


>
> tnx, vy 73 de Roland oe1rsa


------------------------------------------------------------------------------
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Roland Schwarz-2
On 2014-03-29 16:00, SM0SVX wrote:
>
> You are welcome to give it a try. Just read the "Contributing Code"
> documentation first:
>
> https://sourceforge.net/apps/trac/svxlink/wiki/Contributing#Contributingcode
>

Thank you for your patient answering of my questions!
I am a little ashamed now that I discover that you already had
"answered" this last question in detail before I asked it.

I begun to read the code and try to get started by understanding the
async sub library first.

While studying the audio pipline I am wondering if there is already some
coding going on to implement the pulse audio interface. Am I correct in
assumption, that it should be rather straight forward to write an
AsyncAudio device for svxlink? I mean easier than e.g. jack which seems
to have a different philosophy (callbacks, ...)

73 de roland, oe1rsa

--
_________________________________________
  _  _  | Roland Schwarz aka. speedsnail
 |_)(_  | sip:[hidden email]
 | \__) | mailto:[hidden email]
________| http://www.blackspace.at

------------------------------------------------------------------------------
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Flow instead of port forwarding

Tobias Blomberg
On Sunday 06 April 2014 19:53:24 Roland Schwarz wrote:

> On 2014-03-29 16:00, SM0SVX wrote:
> > You are welcome to give it a try. Just read the "Contributing Code"
> > documentation first:
> >
> > https://sourceforge.net/apps/trac/svxlink/wiki/Contributing#Contributingco
> > de
> Thank you for your patient answering of my questions!
> I am a little ashamed now that I discover that you already had
> "answered" this last question in detail before I asked it.
>
> I begun to read the code and try to get started by understanding the
> async sub library first.
>
> While studying the audio pipline I am wondering if there is already some
> coding going on to implement the pulse audio interface. Am I correct in
> assumption, that it should be rather straight forward to write an
> AsyncAudio device for svxlink? I mean easier than e.g. jack which seems
> to have a different philosophy (callbacks, ...)

I don't think anyone is working on PulseAudio support so go right ahead and
add it. If the PulseAudio API is anything like Alsa or OSS it should be
straight forward to implement.

73's de SM0SVX / Tobias


>
> 73 de roland, oe1rsa


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Cubieboard 2 distorted audio

Chris Wilson
In reply to this post by Roland Schwarz-2
Hey Everyone,

I'm having a strange issue with my cubieboard 2, my TX audio is fine,
but my incoming audio is low and very distorted.

Does anyone have any experience with these boards? I see a few people
running them, I am trying to avoid having to use an external usb audio
adapter.

I've seen a few people have mentioned using different ADC levels, but
that does not seem to have any effect.

Any help would be greatly appreciated!

Thanks & 73!

Chris W / N0CSW

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Cubieboard 2 distorted audio

Chris Wilson
Turns out the issue is the physical jack on the cubieboard, not much I
can do :(.

73,

Chris W / N0CSW
On 6/21/2014 9:04 PM, Chris Wilson wrote:

> Hey Everyone,
>
> I'm having a strange issue with my cubieboard 2, my TX audio is fine,
> but my incoming audio is low and very distorted.
>
> Does anyone have any experience with these boards? I see a few people
> running them, I am trying to avoid having to use an external usb audio
> adapter.
>
> I've seen a few people have mentioned using different ADC levels, but
> that does not seem to have any effect.
>
> Any help would be greatly appreciated!
>
> Thanks & 73!
>
> Chris W / N0CSW
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Cubieboard 2 distorted audio

Rob Janssen
Chris Wilson wrote:
> Turns out the issue is the physical jack on the cubieboard, not much I
> can do :(.
>

Are you sure you are setting the correct volume sliders ?
E.g. in alsamixer on the first screen you see (playback) the sliders for Line and Mic
should be zero (muted), and only after pressing F4 you see the (capture) screen
where you set the input source and volume.

Rob

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Cubieboard 2 distorted audio

Chris Wilson
Hey Rob,

Sure Did!

The problem is actually the jack, I found a low profile phone plug and
got it to work, however it was very unreliable, if you moved the plug at
all after you got it seated properly it was back to working horribly.

I've removed the plug and soldered directly to the board, no issues now.
I figured it was better than just junking the board :).

I tried a few things to get it to work right, including contact cleaner
(which helped a little). I'm just chalking it up to a bad plug as
everything is working correctly now without any software modifications.

Thanks a bunch for the recommendation though!!!

Chris W


On 6/22/2014 1:32 AM, Rob Janssen wrote:

> Chris Wilson wrote:
>> Turns out the issue is the physical jack on the cubieboard, not much I
>> can do :(.
>>
> Are you sure you are setting the correct volume sliders ?
> E.g. in alsamixer on the first screen you see (playback) the sliders for Line and Mic
> should be zero (muted), and only after pressing F4 you see the (capture) screen
> where you set the input source and volume.
>
> Rob
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel